Gelir Döngüsü Yönetimi Veri Şablonunuz
Gelir Döngüsü Yönetimi Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
Gelir Döngüsü Yönetimi Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Billing Event BillingEvent | Bir ücret oluşturan tek bir hizmet veya ürün teslimatı için benzersiz tanımlayıcı olup, birincil vaka tanımlayıcısı olarak görev yapar. | ||
| Açıklama Faturalandırma Olayı (Billing Event), belirli bir faturalandırılabilir kalem için gelir döngüsü içindeki tüm aktiviteleri birbirine bağlayan temel tanımlayıcıdır. Bir hizmet sunulduğunda başlar ve hesap tamamen kapatıldığında sona erer. Süreç madenciliği analizinde, bu nitelik her bir ücretin uçtan uca yolculuğunu yeniden yapılandırmak için esastır. Ücret kaydı, talep gönderimi, ödeme kaydı ve ret yönetimi gibi aktivitelerin bireysel faturalandırma olayları için takip edilmesini sağlayarak, süreç akışı ve varyasyonları hakkında net bir görünüm sunar. Neden önemli Bu, her hizmet için gelir oluşturma ve tahsilatın tüm yaşam döngüsünü analiz etmek üzere ilgili tüm süreç adımlarını birbirine bağlamak için kritik olan temel Vaka Kimliği'dir. Nereden alınır Bu, genellikle Epic Resolute'taki bir hastane hesabı (HAR) veya belirli bir ücret oturumu için benzersiz bir tanımlayıcıdır. HAR veya Ücret Oturumu kayıtları gibi belirli tablolar için Epic Resolute belgelerine başvurun. Örnekler BE10098765BE20012345BE30054321 | |||
| Faaliyet Adı ActivityName | Gelir döngüsü yönetimi süreci içinde gerçekleştirilen belirli olayın veya görevin adı. | ||
| Açıklama Bu nitelik, 'Yakalanan Ücretler', 'Ödeme Yapacak Tarafa Gönderilen Talep' veya 'Alınan Ödeme' gibi gelir döngüsündeki tek bir adımı tanımlar. Her aktivite, bir hizmet için faturalandırma ve ödeme tahsilatı sürecinde ayrı bir dönüm noktasını temsil eder. Aktivitelerin analizi, süreç madenciliğinin temelidir. Süreç haritasının görselleştirilmesine, yaygın yolların belirlenmesine, adımlar arasındaki darboğazların keşfedilmesine ve standart işletme prosedürlerine uygunluğun ölçülmesine olanak tanır. Neden önemli Süreç haritasındaki adımları tanımlar, gelir döngüsündeki iş akışını görselleştirmeyi, analiz etmeyi ve optimize etmeyi mümkün kılar. Nereden alınır Bu genellikle Epic Resolute'un faturalandırma ve talep modüllerindeki olay günlüklerinden, denetim izlerinden veya durum değişikliği kayıtlarından türetilir. Örnekler Ücretler YakalandıTalep Ödeyiciye GönderildiÖdeme AlındıHesap Kapatıldı | |||
| Olay Zaman Damgası EventTimestamp | Belirli bir aktivite veya olayın gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay Zaman Damgası (Event Timestamp), bir aktivitenin gerçekleştiği anı kaydeder. Bu zamansal veri, gelir döngüsündeki olayların zamanlamasını ve sıralamasını anlamak için kritik öneme sahiptir. Analizde, zaman damgaları, ücret kaydı gecikmesi veya ödeme kaydı süresi gibi aktiviteler arasındaki süreleri hesaplamak için kullanılır. Darboğazların keşfedilmesini, döngü sürelerinin ölçülmesini ve farklı zaman periyotlarındaki süreç performansının analizini sağlar. Doğru zaman damgaları, neredeyse tüm zaman tabanlı KPI'lar ve dashboard'lar için vazgeçilmezdir. Neden önemli Bu nitelik, gecikmeleri ve verimsizlikleri belirlemek için temel olan döngü süreleri ve süreler dahil olmak üzere tüm zaman tabanlı metrikleri hesaplamak için esastır. Nereden alınır Epic Resolute içindeki işlem veya Örnekler 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Düzeltme Nedeni AdjustmentReason | Bir hastanın hesap bakiyesinde yapılan manuel veya otomatik düzeltmenin nedeni. | ||
| Açıklama Bu nitelik, bir hesap bakiyesinin standart bir ödeme veya ücret dışında neden değiştirildiğini açıklar. Nedenler, ödeme yapanlarla yapılan sözleşmesel indirimler, küçük bakiye silmeleri veya kayıt hatalarının düzeltmeleri olabilir. Bu, 'Hesap Düzeltme Hacmi Türüne Göre' (Account Adjustment Volume By Type) dashboard'u için hayati öneme sahiptir. Düzeltme nedenlerini analiz ederek, kuruluşlar gelir kaybı kaynaklarını belirleyebilir, ödeme yapan sözleşmelerinin etkisini anlayabilir ve faturalandırma sürecindeki potansiyel verimsizlikleri veya hataları tespit edebilir. Neden önemli Hesap bakiyelerinin neden değiştirildiğini açıklayarak gelir kaybı ve faturalandırma doğruluğu hakkında bilgi verir, gereksiz amortismanları azaltmaya yardımcı olur. Nereden alınır Epic Resolute'un hasta muhasebe modülündeki düzeltme girişlerinin işlem detaylarında bulunur. Örnekler Sözleşmeye Dayalı İndirimKüçük Bakiye SilmeYinelenen Ücret Düzeltmesi | |||
| Fatura Departmanı BillingDepartment | Faturalandırma olayı veya aktivitesinden sorumlu departman veya fonksiyonel ekip. | ||
| Açıklama Bu nitelik, faturalandırma olayıyla ilişkili veya belirli bir aktiviteyi gerçekleştiren 'Yatan Hasta Faturalandırma', 'Ayaktan Hasta Faturalandırma' veya 'Ret Yönetim Ekibi' gibi organizasyonel birimi belirtir. Bu boyut, 'Faturalandırma Departmanı Performans Metrikleri' (Billing Department Performance Metrics) dashboard'u için çok önemlidir; ret oranları veya ücret kaydı süreleri gibi temel metriklerin yan yana karşılaştırılmasını sağlar. Yönetimin yüksek performans gösteren departmanları belirlemesine, en iyi uygulamaları standardize etmesine ve kaynakları etkili bir şekilde tahsis etmesine yardımcı olur. Neden önemli Farklı departmanlar arasında performans kıyaslaması yapılmasına olanak tanır, en iyi uygulamaları ve iyileştirme veya ek kaynak gerektiren alanları belirlemeye yardımcı olur. Nereden alınır Bu bilgi, Epic Resolute içindeki kullanıcı kaydına, hasta hesabına veya hizmet konumuna bağlı olabilir. Örnekler Kardiyoloji FaturalandırmaRadyoloji RCMMerkezi Faturalandırma Ofisi | |||
| Hizmet Türü ServiceType | Sunulan tıbbi hizmetin kategorisi veya türü. | ||
| Açıklama Bu nitelik, faturalandırılabilir hizmeti örneğin 'Radyoloji', 'Ameliyat', 'Konsültasyon' veya 'Acil Servis Ziyareti' olarak sınıflandırır. Finansal verilere klinik bağlam sağlar. Hizmet türüne göre gelir döngüsünü analiz etmek, belirli klinik alanlara özgü süreç varyasyonlarını ortaya çıkarabilir. Örneğin, cerrahi prosedürler, standart bir ofis ziyaretine göre daha karmaşık ücret kaydı ve yetkilendirme gereksinimlerine sahip olabilir, bu da farklı süreç davranışlarına ve zorluklara yol açar. Neden önemli Finansal verilere klinik bağlam sağlayarak, farklı tıbbi hizmet türlerinin gelir döngüsü sürecini ve verimliliğini nasıl etkilediğinin analiz edilmesini mümkün kılar. Nereden alınır Epic'teki ücret işlemine bağlı ücret açıklama ana (CDM) dosyasından, hizmet hattından veya departmandan türetilmiştir. Örnekler Yatan Hasta CerrahisiAyakta RadyolojiAcil Servisler | |||
| Ret Gerekçe Kodu DenialReasonCode | Bir ödeyicinin sunulan bir talebi neden reddettiğini belirten standartlaştırılmış bir kod. | ||
| Açıklama Bir ödeme yapacak taraf bir talebi reddettiğinde, 'Kapsam Dışı Hizmet', 'Tekrar Eden Talep' veya 'Ek Bilgi Gerektirir' gibi reddi açıklayan bir neden kodu sağlar. Bu kodlar genellikle Talep Düzeltme Neden Kodları (CARC'ler) olarak standartlaştırılmıştır. Bu nitelik, 'Talep Ret Oranları ve Nedenleri' (Claim Denial Rates And Reasons) dashboard'unun temel taşıdır. Farklı ret kodlarının sıklığını analiz etmek, kimlik bilgisi sorunları, kodlama hataları veya eksik ön yetkilendirmeler gibi retlerin temel nedenlerini belirlemeye yardımcı olur ve hedeflenmiş iyileştirme girişimlerine olanak tanır. Neden önemli Taleplerin neden reddedildiğini doğrudan açıklar, ret oranlarını azaltmak, gelir kaybını önlemek ve ödemeleri hızlandırmak için gereken eyleme dönüştürülebilir içgörüler sağlar. Nereden alınır Bu veri, ödeme yapacak taraflardan alınan ve Epic Resolute'un talep yönetimi modülünde depolanan talep yanıt işlemlerinde (ANSI 835 dosyası gibi) bulunur. Örnekler CO-16: Talep/hizmet bilgisi eksikOA-18: Yinelenen talep/hizmetPR-96: Kapsam dışı ücret(ler) | |||
| Sorumlu Kullanıcı ResponsibleUser | Aktiviteyi gerçekleştiren kullanıcı veya çalışanın tanımlayıcısı. | ||
| Açıklama Bu nitelik, gelir döngüsünde belirli bir görevi tamamlamaktan sorumlu kişinin kullanıcı kimliğini, adını veya çalışan numarasını yakalar. Bu, ücretleri giren klinisyen, talep gönderen faturalama görevlisi veya ret takibi yapan tahsilat görevlisi olabilir. Kullanıcı bazında analiz yapmak, en iyi performans gösterenleri belirlemeye, eğitim ihtiyaçlarını tespit etmeye ve iş yükü dağılımını anlamaya yardımcı olur. Performans yönetimi ve belirli bireyler veya rollerle ilişkili süreç sapmalarını araştırmak için anahtardır. Neden önemli Bireysel veya role göre performans analizi yapılmasına olanak tanır, eğitim fırsatlarını, iş yükü dengesizliklerini ve kaynakla ilgili darboğazları belirlemeye yardımcı olur. Nereden alınır Genellikle Epic Resolute içindeki denetim izinde veya işlem günlüklerinde bulunur, genellikle bir kullanıcı ana veri tablosuna (örn. EMP kaydı) bağlıdır. Örnekler j.doebsmith123User7890 | |||
| Vadesi Geçmiş Bakiye OutstandingBalance | Faturalandırma olayı için ödeme yapacak taraftan veya hastadan kalan ödenmesi gereken miktar. | ||
| Açıklama Bu nitelik, aktivite anında belirli bir faturalandırma olayı için mevcut alacak hesapları bakiyesini temsil eder. Vakanın yaşam döngüsü boyunca finansal durumunu yansıtır. Kalan bakiye, finansal raporlama ve 'Ödenmemiş Bakiye Yaşlandırma Raporu' (Outstanding Balance Aging Report) için kritik öneme sahiptir. Bu değeri zaman içinde ve ödeme yapan veya departman gibi farklı boyutlara göre analiz etmek, tahsilat çabalarına öncelik vermeye, nakit akışını yönetmeye ve finansal riski değerlendirmeye yardımcı olur. Neden önemli Süreç gecikmelerinin finansal etkisini doğrudan ölçer ve tahsilatları önceliklendirmek, nakit akışını yönetmek ve alacak hesaplarını anlamak için esastır. Nereden alınır Bu, Epic Resolute'taki hasta hesabı veya hastane hesabı (HAR) kaydındaki temel bir alandır. Finansal işlemlerle güncellenen yürüyen bir bakiyedir. Örnekler 1500.00250.750.00 | |||
| Claim ID ClaimId | Bir ödeme yapacak tarafa sunulan sigorta talebine atanan benzersiz tanımlayıcı. | ||
| Açıklama Bu nitelik, ödeme yapacak tarafa gönderilen talep formunun (örneğin, bir CMS-1500 veya UB-04) belirli kimliğidir. Hizmetler yeniden faturalandırılırsa veya itiraz edilirse, tek bir faturalandırma olayı birden fazla talep içerebilir. Talep Kimliği (Claim ID) ile takip, talep gönderimi ve ret yönetimi alt süreçlerinin detaylı analizi için faydalıdır. Başlangıçtaki taleple ilgili aktiviteleri, aynı hizmet için sonraki, yeniden gönderilen bir taleple ilgili olanlardan ayırmaya yardımcı olur. Neden önemli Her bir talep başvurusunun yaşam döngüsünü takip etmek için detaylı bir tanımlayıcı sağlar, bu da yeniden başvuruları ve itirazları analiz etmek için kritik öneme sahiptir. Nereden alınır Epic Resolute'un talep yönetimi modülü tarafından bir talep oluşturulduğunda üretilir. Talep Örnekler CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Düzeltilen Tutar AdjustedAmount | Bir düzeltme işleminin parasal değeri. | ||
| Açıklama Bu alan, bir hesap düzeltmesinin belirli dolar miktarını kaydeder. Hesap bakiyesine bir alacak veya borç temsil eden pozitif veya negatif bir değer olabilir. Bu miktar, 'Hesap Düzeltme Hacmi Türüne Göre' (Account Adjustment Volume By Type) dashboard'u için birincil metriktir. Bu değeri düzeltme nedenine göre toplamak, sözleşmesel yükümlülükler nedeniyle ne kadar gelirin silindiği ile düzeltilebilir hatalar nedeniyle ne kadarının kaybedildiği gibi farklı düzeltme türlerinin finansal etkisine dair net bir tablo sunar. Neden önemli Hesap düzenlemelerinin finansal etkisini nicel olarak belirler, böylece gelir kaybını ve faturalandırma hatalarının maliyetini ölçmeyi mümkün kılar. Nereden alınır Epic Resolute'taki finansal işlem detay tablolarında bulunur, düzeltme türü işlemlerle ilişkilidir. Örnekler -1250.45-50.0025.10 | |||
| Hasta ID PatientId | Hizmeti alan hasta için benzersiz tanımlayıcı. | ||
| Açıklama Bu nitelik, hastanın Tıbbi Kayıt Numarası (MRN) veya diğer benzersiz tanımlayıcısıdır. Finansal faturalandırma olayını belirli bir bireye bağlar. Hasta gizliliğini korumak amacıyla genellikle birincil analiz boyutu olarak kullanılmasa da, veri doğrulama için esastır ve tek bir hastanın tüm faturalandırma olaylarını bir araya getirerek genel finansal yolculuğunu anlamak için kullanılabilir. Ayrıca, klinik süreç verileriyle potansiyel entegrasyon için de kritik öneme sahiptir. Neden önemli Finansal data'yı belirli bir hastaya bağlar, Nereden alınır Epic genelinde bulunan, hastanın kayıt ve hesap kayıtlarına bağlı temel bir tanımlayıcı. Örnekler MRN-1234567MRN-8765432MRN-5551234 | |||
| İşlem Süresi ProcessingTime | Bir etkinlik üzerinde aktif olarak çalışılan sürenin hesaplanmış süresi. | ||
| Açıklama İşlem süresi veya diğer adıyla operasyon süresi, bir aktivitenin başlangıcından bitişine kadar geçen süreyi ölçer. Bu, bir kaynağın görevle aktif olarak ilgilendiği zamanı temsil eder. Bu metrik, 'EventEndTime' ve 'EventTimestamp' arasındaki fark olarak hesaplanır. İşlem süresini analiz etmek, hangi belirli görevlerin en çok zaman aldığını belirlemeye yardımcı olur; bu da verimliliği artırmak ve süreçleri kolaylaştırmak için odaklanılmış çabalara olanak tanır. Kaynak verimliliğinin temel bir ölçüsüdür. Neden önemli Aktivitelerin gerçek çalışma süresini ölçer, zaman alıcı görevleri belirlemeye ve kaynakların verimliliğini değerlendirmeye yardımcı olur. Nereden alınır Bu, kaynak sistemde bir alan değildir. Veri dönüşümü sırasında 'EventEndTime - EventTimestamp' formülü kullanılarak hesaplanır. Örnekler 900605120 | |||
| Kaynak Sistem SourceSystem | Verilerin kaynaklandığı bilgi sistemi. | ||
| Açıklama Bu nitelik, kaydın kaynak sistemini tanımlar ki bu bağlamda Epic Resolute'tur. Birden fazla entegre sistemin olduğu ortamlarda, bu alan veri kaynaklarını ayırt etmeye yardımcı olur. Tek sistemli bir görünümde gereksiz gibi görünse de, veri yönetimi ve ölçeklenebilirlik için en iyi uygulamadır. Daha sonra ayrı bir tahsilat ajansı platformu gibi başka sistemlerden veri entegre edildiğinde netlik sağlar. Neden önemli Verinin kaynağı hakkında netlik sağlayarak veri kökeni ve bağlamı açısından kritik bilgiler sunar, bu da veri yönetimi ve sorun giderme için hayati öneme sahiptir. Nereden alınır Bu genellikle veri çıkarma ve dönüştürme süreci sırasında veri setinin kaynağını etiketlemek için eklenen statik bir değerdir. Örnekler Epic ResoluteEpicResolute_V2023 | |||
| Ödeyen Adı PayerName | Ödemeden sorumlu sigorta şirketinin, devlet kurumunun veya diğer tarafın adı. | ||
| Açıklama Bu nitelik, faturalandırma olayıyla ilişkili birincil ödeme yapacak tarafı tanımlar; örneğin 'Blue Cross Blue Shield', 'Medicare' veya 'Aetna'. Kendi ödemesini yapan durumlarda ise hastayı gösterebilir. Süreci ödeme yapacak tarafa göre segmentlere ayırmak güçlü bir analiz tekniğidir. Bazı ödeme yapanların daha yüksek ret oranlarına, daha uzun ödeme döngülerine veya daha karmaşık gereksinimlere sahip olduğunu ortaya çıkarabilir. Bu içgörü, verimliliği ve ödeme hızını artırmak için faturalandırma stratejilerini belirli ödeme yapanlara göre uyarlamaya olanak tanır. Neden önemli Ödeyiciye göre performans analizi yapılmasına olanak tanır, hangi ödeyicilerin yüksek ret oranlarına veya yavaş ödeme döngülerine sahip olduğunu ortaya çıkarır ve hedefe yönelik takip stratejileri sağlar. Nereden alınır Bu bilgi, hastanın kapsam detaylarının bir parçasıdır ve Epic Resolute'taki hastane hesabına (HAR) bağlıdır. Örnekler Medicare Part BUnitedHealthcareAetna PPO | |||
| Olay Bitiş Zamanı EventEndTime | Bir aktivitenin ne zaman tamamlandığını gösteren zaman damgası, aktivite süresini hesaplamak için faydalıdır. | ||
| Açıklama Bu nitelik, bir aktivitenin tamamlanma süresini kaydeder. Birçok aktivite Başlangıç Zamanı'nın Bitiş Zamanı'na eşit olduğu anlık olaylar olsa da, bazı görevlerin (örneğin, bir ret takibi araması) ölçülebilir bir süresi vardır. Mevcut olduğunda, Bitiş Zamanı, aktivite işlem süresinin ('Bitiş Zamanı' - 'Başlangıç Zamanı') doğrudan hesaplanmasına olanak tanır. Bu, sonraki aktivitenin başlangıç zamanından süre çıkarmaktan daha doğrudur, çünkü adımlar arasındaki boşta kalma süresini hesaba katar. 'ProcessingTime' niteliğini hesaplamak için temel bir bileşendir. Neden önemli Her bir aktivitenin tamamlanmasının ne kadar sürdüğünün hassas bir şekilde hesaplanmasını sağlar, bu da verimsiz görevleri belirlemek ve kaynak verimliliğini ölçmek için hayati öneme sahiptir. Nereden alınır Bu, Epic Resolute'taki iş kuyruğu (work queue) veya aktivite yönetimi günlükleri gibi görev başlangıcını ve bitişini izleyen bazı modüllerde mevcut olabilir. Genellikle açıkça takip edilmez. Örnekler 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Otomatikleştirildi mi? IsAutomated | Aktivitenin bir sistem veya otomatik bir süreç tarafından gerçekleştirilip gerçekleştirilmediğini gösteren boolean bir bayrak. | ||
| Açıklama Bu işaret, sistem tarafından otomatik olarak yürütülen görevler (otomatik talep oluşturma veya uygunluk kontrolleri gibi) ile bir kullanıcı tarafından manuel olarak gerçekleştirilen görevler arasında ayrım yapar. Bu niteliği analiz etmek, süreçteki otomasyon seviyesini anlamaya yardımcı olur. Otomatik ve manuel aktivitelerin verimlilik ve hata oranlarını karşılaştırmak, daha fazla otomasyon fırsatlarını belirlemek ve mevcut botların veya sistem kurallarının performansını izlemek için kullanılabilir. Neden önemli Sistem odaklı ve insan odaklı aktiviteler arasında ayrım yapar, bu da otomasyonun etkisini değerlendirmek ve yeni otomasyon fırsatlarını belirlemek için anahtardır. Nereden alınır Bu genellikle bir aktivite için 'SorumluKullanıcı'nın bir sistem veya hizmet hesabı olup olmadığını kontrol ederek veya otomatik olduğu bilinen belirli aktivite adlarını işaretleyerek elde edilir. Örnekler truefalse | |||
| Son Ödeme Tarihi PaymentDueDate | Faturalandırılan hizmetin ödemesinin beklendiği tarih. | ||
| Açıklama Bu nitelik, faturada belirtilen veya ödeme yapacak taraf sözleşmeleriyle belirlenen ödeme son tarihini belirtir. Zamanında yapılan ödemeleri ölçmek için bir referans noktası görevi görür. Ödeme son tarihi, 'Ödenmemiş Bakiye Yaşlandırma Raporu'nu oluşturmak için esastır. Mevcut tarihi, açık bakiyelerin son ödeme tarihiyle karşılaştırarak, alacak hesapları yaşlandırma gruplarına (örn. 0-30 gün, 31-60 gün gecikmiş) ayrılabilir, bu da en gecikmiş hesaplar üzerindeki tahsilat çabalarına öncelik vermeye yardımcı olur. Neden önemli Alacak hesapları yaşlandırma analizinin temelini oluşturur; bu da tahsilatlara öncelik vermek ve ödenmeyen faturalardan kaynaklanan finansal riski yönetmek için kritik öneme sahiptir. Nereden alınır Bu tarih genellikle Epic içindeki ödeme yapacak taraf sözleşmesi veya hasta hesap bilgilerinde saklanan fatura tarihi ve ödeme koşullarına göre hesaplanır. Örnekler 2023-05-302023-06-152023-07-01 | |||
| Son Veri Güncellemesi LastDataUpdate | Bu event'e ait verinin en son ne zaman yenilendiğini veya kaynak sistemden çıkarıldığını gösteren timestamp. | ||
| Açıklama Bu nitelik, verinin güncelliğini gösterir. Kaydın en son ne zaman Epic Resolute'tan süreç madenciliği veri setine çekildiğini belirtir. Bu, analizin güncelliğini ve veri doğrulama amaçlarını anlamak için önemlidir. Kullanıcıların mevcut en güncel bilgilere bakıp bakmadıklarını bilmelerine yardımcı olur ve veri yenileme döngülerini yönetmek için kritik öneme sahiptir. Neden önemli Kullanıcıların analiz ettikleri data'nın güncelliğini anlamalarını sağlar, bu da doğru, güncel iş kararları almak için kritik öneme sahiptir. Nereden alınır Bu zaman damgası, veri alımı sırasında ETL (Extract, Transform, Load) süreci tarafından eklenir. Örnekler 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Toplam Gelir Döngüsü Süresi TotalRevenueCycleTime | İlk hizmet olayından nihai ödemeye veya hesap kapanışına kadar hesaplanan toplam süre. | ||
| Açıklama Bu, tek bir faturalandırma olayı için gelir döngüsünün uçtan uca süresini ölçen vaka düzeyinde bir KPI'dır. Genellikle 'Hizmet Verildi' aktivitesi ile son 'Ödeme Alındı' veya 'Hesap Kapandı' aktivitesi arasındaki zaman farkı olarak hesaplanır. Bu üst düzey metrik, RCM sürecinin genel verimliliğine bütünsel bir bakış açısı sağlar. Bu KPI'yı zaman içinde takip etmek, süreç iyileştirme girişimlerinin etkisini ölçmeye yardımcı olur ve nakit dönüşüm hızının temel bir göstergesini sunar. Neden önemli Süreç verimliliğinin üst düzeyden, uçtan uca bir görünümünü sunar; bir hizmetin nakde dönüşme süresini doğrudan ölçer. Nereden alınır Bu, süreç madenciliği aracı içinde her vakanın ilk ve son olaylarını filtreleyerek ve zaman farkını bularak hesaplanan bir metriktir. Örnekler 259200038880005184000 | |||
Gelir Döngüsü Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hesap Kapatıldı | Bu, faturalandırma olayının kalan bakiyesinin sıfıra ulaştığını ve bekleyen başka aktivite olmadığını belirten son aktivitedir. Bu, tam ödeme, düzeltmeler veya bir silme işleminden kaynaklanabilir. | ||
| Neden önemli Bu olay, bir faturalandırma olayının gelir döngüsünün başarılı bir şekilde tamamlanmasını işaret eder. Hizmetten kapanışa kadar geçen uçtan uca süre, genel süreç verimliliği için kritik bir KPI'dır. Nereden alınır Bu tipik olarak çıkarımsal bir olaydır. Faturalandırma olayına ilişkin hesap bakiyesinin sıfır olduğu ve sıfır kaldığı zaman noktasının belirlenmesiyle saptanır. Yakala Hesap bakiyesinin çalışan toplamını hesaplayarak ve bakiyeyi sıfırlayan son işlemin Event tipi inferred | |||
| Hizmet Verildi | Bu aktivite, hastaya klinik bir hizmetin sağlandığı noktayı işaret eder ve bu da faturalandırma olayını başlatır. Bu genellikle bir klinisyenin bir ziyaret veya prosedürü onayladığında Epic EHR (EpicCare) sisteminden yakalanır. | ||
| Neden önemli Bu, gelir döngüsü için birincil başlangıç olayıdır. Bu noktadan ücret kaydına kadar geçen süreyi analiz etmek, faturalandırma başlangıcındaki gecikmeleri ve potansiyel gelir kaybını belirlemek için kritik öneme sahiptir. Nereden alınır Bu olay tipik olarak, faturalandırma hesabına bağlı klinik modüllerdeki hizmet veya ziyaret zaman damgalarından çıkarılır. Ücret işlemindeki hizmet tarihi, ana veri noktasıdır. Yakala
Event tipi inferred | |||
| Ödeme Alındı | Ödeme yapacak taraftan veya hastadan ödeme alındığını temsil eder. Bu olay tipik olarak elektronik ödeme bildirimi (ERA) yüklendiğinde veya sisteme manuel bir çek girildiğinde kaydedilir. | ||
| Neden önemli Bu aktivite, gelirin gelmekte olduğunu gösteren önemli bir dönüm noktasıdır. Talep gönderimi ile ödeme alımı arasındaki süre, alacak hesapları performansının temel bir ölçüsüdür. Nereden alınır Resolute'ta bir ödeme işlemi olarak açıkça kaydedilir. Bu işlemler bir tarih, kaynak ve tutar ile günlüğe kaydedilir, genellikle bireysel ücretlere tam olarak kaydedilmeden önce. Yakala Finansal işlem kaydından, genellikle belirli işlem türleriyle tanımlanan ödeme işlemlerini yakalayın. Event tipi explicit | |||
| Ödeme Hesaba Kaydedildi | Bu, alınan bir ödemenin hastanın hesabındaki belirli ücretlere uygulandığı veya tahsis edildiği olaydır. Bu eylem, faturalandırma olayının kalan bakiyesini azaltır. | ||
| Neden önemli Verimli ödeme kaydı, doğru hesap bakiyelerini korumak ve Nereden alınır Bu, Resolute'ta açık bir işlemdir. Ödeme kaydı, bir ödeme işlemini bir veya daha fazla ücret işlemine bağlar ve bu, işlem detay tablolarında kaydedilir. Yakala Bir ödemeyi bir ücrete uygulayan, belirli işlem türleriyle tanımlanabilen işlem kaydını yakalayın. Event tipi explicit | |||
| Talep Ödeyici Tarafından Reddedildi | Ödeme yapacak taraftan talebin reddedildiğine dair bir bildirimin alındığını temsil eder. Bu, Epic'in elektronik bir ödeme bildirimi (835 dosyası) işlediğinde veya bir kullanıcının reddi manuel olarak kaydettiğinde yakalanır. | ||
| Neden önemli Bu aktivite, kritik bir yeniden işleme döngüsünü başlatır. Ret nedenlerini ve hacimlerini analiz etmek, temel nedenleri belirlemek, ilk geçiş ödeme oranlarını iyileştirmek ve tahsilat gecikmelerini azaltmak için esastır. Nereden alınır Talep üzerinde bir işlem veya durum güncellemesi olarak açıkça kaydedilir. Gerekçe kodları dahil ret bilgileri, genellikle elektronik olarak alınır ve hesaba kaydedilir. Yakala Reddi gösteren belirli işlem türlerini veya talep durumu güncellemelerini filtreleyin. Event tipi explicit | |||
| Talep Ödeyiciye Gönderildi | Bu, talebin resmi olarak sigorta ödeme yapacak tarafa yargılama için gönderildiği olayı işaret eder. Epic'te bu, elektronik talep dosyasının takas odasına veya ödeme yapacak tarafa iletildiğinde kaydedilen izlenen bir olaydır. | ||
| Neden önemli Bu dönüm noktası kritik öneme sahiptir çünkü ödeme yapacak tarafın ödeme zaman çizelgesini başlatır. Bunu analiz etmek, talep iletim sürecinin verimliliğini ölçmeye yardımcı olur ve Faturadan Ödeme Yapacak Tarafa Teslim Süresi KPI'ını destekler. Nereden alınır Bu, Resolute'ta kaydedilen açık bir olaydır. Talep kaydında bir gönderim durumu ve ne zaman gönderildiğini gösteren bir zaman damgası bulunur. Yakala Talep durumunun 'Submitted' veya 'Transmitted' olarak değişmesiyle ilişkili Event tipi explicit | |||
| Ücretler Yakalandı | Sunulan hizmetler için faturalandırılabilir ücretlerin resmi kaydını temsil eder. Epic'te bu genellikle hastanın hesabına gönderilen, klinik eylemlerden otomatik olarak oluşturulan veya manuel olarak girilen açık bir işlemdir. | ||
| Neden önemli Bu kritik bir ilk dönüm noktasıdır. Ücret kaydının hızını ve doğruluğunu ölçmek, faturalandırma sürecini hızlandırmaya ve sağlanan tüm hizmetlerin faturalandırılmasını sağlamaya yardımcı olur. Nereden alınır Resolute'un işlem loglarında açıkça kaydedilir. Her ücret, bir kayıt tarihi, hizmet tarihi ve tutarı ile ayrı bir giriştir ve genellikle ARPB_TRANSACTIONS gibi tablolarda bulunur. Yakala Sistemin finansal işlem kaydından ücret kaydı işlemlerini yakalayın. Event tipi explicit | |||
| Bakiye Tahsilata Gönderildi | Bu, ödenmemiş bir hesap bakiyesinin dahili veya harici bir tahsilat sürecine aktarıldığı noktayı işaret eder. Bu genellikle hesapta veya faturalandırma olayında açık bir durum değişikliğidir. | ||
| Neden önemli Bu aktivite, ödenmemiş bakiyeleri geri kazanma sürecinin son aşamasını başlatır. Tahsilat sürecinin başarı oranını ve döngü süresini takip etmek, kötü alacakları en aza indirmek için hayati öneme sahiptir. Nereden alınır Bu tipik olarak açık bir olaydır. Epic'te hesapları tahsilat ajanslarına aktarma işlevleri bulunur, bu da hesapta bir günlük girişi veya durum değişikliği oluşturur. Yakala Bir hesabın bir tahsilat ajansına yerleştirildiğini gösteren durum değişikliğini veya işlemi belirleyin. Event tipi explicit | |||
| Hesap Düzeltmesi Yapıldı | Bu aktivite, sözleşmesel bir düzenleme, küçük bakiye silme veya iyi niyet indirimi gibi hesap bakiyesini değiştiren bir ödeme dışı işlemi temsil eder. Bu, belirli bir işlem türü olarak kaydedilir. | ||
| Neden önemli Düzeltmeleri analiz etmek, gelir kaybını belirlemenin anahtarıdır. Belirli düzeltme türlerinin yüksek hacimleri, ücret tarifeleri, sözleşmeler veya iç politikalarla ilgili sorunları gösterebilir. Nereden alınır Resolute'un finansal loglarında düzeltme işlemleri olarak açıkça kaydedilir. Her düzeltme, belirli bir tür veya gerekçe kodu ile ilişkilendirilecektir. Yakala Finansal düzeltmelere veya silmelere karşılık gelen işlem türlerini filtreleyin. Event tipi explicit | |||
| Ret Takibi Başlatıldı | Bu aktivite, reddedilen bir talebi inceleme ve çözme iç sürecinin başlangıcını işaret eder. Genellikle bir kullanıcı bir iş kuyruğunda (workqueue) reddedilen talebin sorumluluğunu üstlendiğinde veya durumunu değiştirdiğinde yakalanır. | ||
| Neden önemli Bunu takip etmek, ret yönetimi ekibinin duyarlılığını ölçmeye yardımcı olur. Bir ret ile takibin başlangıcı arasındaki gecikmeler, gelir döngüsünü gereksiz yere uzatabilir. Nereden alınır Bu tipik olarak, Epic'in iş kuyrukları (workqueues) içindeki talebin durumundaki veya atama geçmişindeki değişikliklerden çıkarılır. Örneğin, talebin durumu 'Reddedildi'den 'İncelemede'ye değişebilir. Yakala Bir talep durumu değişikliğinden veya bir kullanıcının ret üzerinde çalışmaya başladığını gösteren bir denetim log girişinden çıkarım yapın. Event tipi inferred | |||
| Talep Oluşturuldu | Bu aktivite, sistemin yakalanan ücretlere dayanarak resmi bir talep veya fatura oluşturmasını ifade eder. Bu, talebin ödeme yapacak tarafa veya hastaya gönderilmeden önceki hazırlık adımıdır. | ||
| Neden önemli Talep oluşturmayı takip etmek, ücretleri yakalama ile gönderime hazırlama arasındaki gecikmeleri izole etmeye yardımcı olur. Bu, genel faturalandırma zamanlamasını etkileyebilecek önemli bir dahili adımdır. Nereden alınır Bu tipik olarak bir faturalandırma veya talep oluşturma toplu işi çalıştığında kaydedilir. Sistem, belirli bir hesap için talep dosyası (837 dosyası gibi) oluşturulduğunda bir zaman damgası kaydedecektir. Yakala Talebin derlendiğini ve gönderime hazır olduğunu gösteren log girişlerini veya durum değişikliklerini belirleyin. Event tipi explicit | |||
| Talep Yeniden Sunuldu | Bu olay, reddedilen bir talebin düzeltildikten sonra ödeme yapacak tarafa geri gönderilmesiyle gerçekleşir. Bu, orijinal taleple bağlantılı ayrı bir gönderim olayıdır. | ||
| Neden önemli Bu, yeniden işleme döngüsünün önemli bir parçasıdır. Yeniden başvuru süresini ve yeniden gönderilen taleplerin başarı oranını ölçmek, ret çözüm sürecinin etkinliğini anlamak için hayati öneme sahiptir. Nereden alınır Bu, ilk gönderime benzer, ancak genellikle yeniden gönderim olarak işaretlenen açık bir olaydır. Talep kaydında yeni bir gönderim zaman damgası gösterilecek ve bir yeniden gönderim kodu içerebilir. Yakala Düzeltme veya yeniden gönderim olarak işaretlenmiş bir talep gönderimi için Event tipi explicit | |||
Veri Çekim Kılavuzları
Adımlar
- Veritabanı Bağlantısı Kurun: Epic Clarity veritabanı için salt okunur kimlik bilgilerini edinin. Veritabanı sunucusuna bağlanmak için DBeaver veya Microsoft SQL Server Management Studio gibi standart bir SQL istemcisi kullanın.
- Temel Tabloları Belirleyin: Bu çıkarma için birincil tablolar arasında vaka bilgileri için
HSP_ACCOUNT, finansalevent'ler içinHSP_TRANSACTIONS, talep durumu içinCLP_CLAIM_INFOve ödeme kaydı ayrıntıları içinF_ARHB_TX_SET_POST_HXbulunur. Ayrıca kullanıcı ayrıntıları içinCLARITY_EMPgibi ana dosyaları da birleştireceksiniz. - Kapsamı Tanımlayın: Sorguyu yazmadan önce analizinizin kapsamını belirleyin. Tipik olarak 3 ila 6 aylık belirli bir tarih aralığı tanımlayın ve dahil etmek veya hariç tutmak istediğiniz belirli hastane hizmet alanlarını (
SERV_AREA_ID) veya hesap sınıflarını belirleyin. - SQL Sorgusunu Geliştirin: Tanımladığınız kapsamda yer alan
HSP_ACCOUNT_IDdeğerlerini ilk olarak seçmek için Ortak Tablo İfadesi (CTE) kullanarak bir SQL sorgusu oluşturun. Bu, faturalandırmaevent'lerinin temel popülasyonu olarak hizmet edecektir. - Bireysel Aktivite Sorgularını Birleştirin: Gerekli 12
activity'nin her biri için, ilgili tablolardandataalan ayrı birSELECTifadesi yazın. Yalnızca hedeflenen hesapları analiz ettiğinizden emin olmak için başlangıçtaki CTE'nize geri birleştirin. - Sorguları
UNION ALLile Birleştirin: Tüm bireyselactivitysorgularından gelen sonuçları tek, tutarlı birevent log'da birleştirmek içinUNION ALLoperatörünü kullanın. Bu, her sorgudan gelen satırları dikey olarak birleştirir. - Standart Şemaya Eşleştirin: Her
SELECTifadesinde, sütunları gerekli ProcessMind şemasına eşleştirmek için takma ad verin:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, vb. Belirli biractivityiçin geçerli olmayan öznitelikler içinNULLkullanın. - Sorguyu Çalıştırın ve İyileştirin: Sorgunun tamamını Clarity veritabanına karşı çalıştırın. Tabloların boyutu nedeniyle bu önemli miktarda zaman alabilir. Performans bir sorunsa, tarih aralığını daha da kısıtlayın veya başlangıçtaki CTE'ye daha spesifik filtreler ekleyin.
- Çıktıyı İnceleyin: Sorgu tamamlandığında, çıktının ilk birkaç yüz satırını inceleyin. Tüm sütunların mevcut olduğunu,
timestamp'lerin tutarlı bir formatta olduğunu ve farklıActivityNamedeğerlerinin beklendiği gibi göründüğünü doğrulayın. - CSV'ye Aktarın: Tüm sonuç kümesini SQL istemcinizden bir CSV dosyasına aktarın. Dosyanın UTF-8 kodlamasını kullandığından ve doğru sütun adlarıyla bir başlık satırı içerdiğinden emin olun.
- Yüklemeye Hazırlanın: ProcessMind'e yüklemeden önce, biçimlendirme hataları olup olmadığını doğrulamak için CSV dosyasını açın. Örneğin,
YYYY-MM-DD HH:MI:SSgibitimestampformatının tutarlı olduğunu kontrol edin. Dosya şimdi alıma hazır.
Konfigürasyon
- Veritabanı Bağlantısı: Epic Clarity veritabanına erişimi olan salt okunur bir kullanıcı hesabı gereklidir.
- Tarih Aralığı Parametreleri: Sağlanan sorgu
@StartDateve@EndDatedeğişkenlerini kullanır. Bunlar analiz dönemini tanımlamak için ayarlanmalıdır. Veri hacmi ile performansı dengelemek için 3 ila 6 aylık bir aralık önerilir. - Tablo ve Sütun Eşleştirme: Sorgu, standart Clarity tablo ve sütun adlarını varsayar. Kurumunuzun özel Epic yapılandırması veya sürümü farklılıklar gösterebilir. Buna göre tablo adlarını, sütun adlarını veya birleştirme koşullarını ayarlamanız gerekebilir.
- İşlem ve Durum Kodları: Sorgu,
[Reddetme İşlem Türünüz]ve[Tahsilat Durum Kodunuz]gibi yer tutucular içerir. Kurumunuz için doğru kodları bulmak amacıyla Epic sistem yöneticilerinize danışmanız veyaZC_TX_TYPEveyaZC_ACCOUNT_STATUSgibi ilgili ana dosyaları incelemeniz gerekmektedir. - Filtreleme: Daha iyi performans ve daha odaklı bir analiz için, başlangıçtaki
BaseAccountsCTE'sine filtreler ekleyin. Yaygın filtreler arasında hastane hizmet alanına göre sınırlamak içinSERV_AREA_IDveya Yatan Hasta veya Ayakta Tedavi faturalandırmasına odaklanmak içinACCOUNT_CLASS_Cbulunur.
a Örnek Sorgu sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Adımlar
- Veritabanı Bağlantısı Kurun: Epic Clarity veritabanı için salt okunur kimlik bilgilerini edinin. Veritabanı sunucusuna bağlanmak için DBeaver veya Microsoft SQL Server Management Studio gibi standart bir SQL istemcisi kullanın.
- Temel Tabloları Belirleyin: Bu çıkarma için birincil tablolar arasında vaka bilgileri için
HSP_ACCOUNT, finansalevent'ler içinHSP_TRANSACTIONS, talep durumu içinCLP_CLAIM_INFOve ödeme kaydı ayrıntıları içinF_ARHB_TX_SET_POST_HXbulunur. Ayrıca kullanıcı ayrıntıları içinCLARITY_EMPgibi ana dosyaları da birleştireceksiniz. - Kapsamı Tanımlayın: Sorguyu yazmadan önce analizinizin kapsamını belirleyin. Tipik olarak 3 ila 6 aylık belirli bir tarih aralığı tanımlayın ve dahil etmek veya hariç tutmak istediğiniz belirli hastane hizmet alanlarını (
SERV_AREA_ID) veya hesap sınıflarını belirleyin. - SQL Sorgusunu Geliştirin: Tanımladığınız kapsamda yer alan
HSP_ACCOUNT_IDdeğerlerini ilk olarak seçmek için Ortak Tablo İfadesi (CTE) kullanarak bir SQL sorgusu oluşturun. Bu, faturalandırmaevent'lerinin temel popülasyonu olarak hizmet edecektir. - Bireysel Aktivite Sorgularını Birleştirin: Gerekli 12
activity'nin her biri için, ilgili tablolardandataalan ayrı birSELECTifadesi yazın. Yalnızca hedeflenen hesapları analiz ettiğinizden emin olmak için başlangıçtaki CTE'nize geri birleştirin. - Sorguları
UNION ALLile Birleştirin: Tüm bireyselactivitysorgularından gelen sonuçları tek, tutarlı birevent log'da birleştirmek içinUNION ALLoperatörünü kullanın. Bu, her sorgudan gelen satırları dikey olarak birleştirir. - Standart Şemaya Eşleştirin: Her
SELECTifadesinde, sütunları gerekli ProcessMind şemasına eşleştirmek için takma ad verin:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, vb. Belirli biractivityiçin geçerli olmayan öznitelikler içinNULLkullanın. - Sorguyu Çalıştırın ve İyileştirin: Sorgunun tamamını Clarity veritabanına karşı çalıştırın. Tabloların boyutu nedeniyle bu önemli miktarda zaman alabilir. Performans bir sorunsa, tarih aralığını daha da kısıtlayın veya başlangıçtaki CTE'ye daha spesifik filtreler ekleyin.
- Çıktıyı İnceleyin: Sorgu tamamlandığında, çıktının ilk birkaç yüz satırını inceleyin. Tüm sütunların mevcut olduğunu,
timestamp'lerin tutarlı bir formatta olduğunu ve farklıActivityNamedeğerlerinin beklendiği gibi göründüğünü doğrulayın. - CSV'ye Aktarın: Tüm sonuç kümesini SQL istemcinizden bir CSV dosyasına aktarın. Dosyanın UTF-8 kodlamasını kullandığından ve doğru sütun adlarıyla bir başlık satırı içerdiğinden emin olun.
- Yüklemeye Hazırlanın: ProcessMind'e yüklemeden önce, biçimlendirme hataları olup olmadığını doğrulamak için CSV dosyasını açın. Örneğin,
YYYY-MM-DD HH:MI:SSgibitimestampformatının tutarlı olduğunu kontrol edin. Dosya şimdi alıma hazır.
Konfigürasyon
- Veritabanı Bağlantısı: Epic Clarity veritabanına erişimi olan salt okunur bir kullanıcı hesabı gereklidir.
- Tarih Aralığı Parametreleri: Sağlanan sorgu
@StartDateve@EndDatedeğişkenlerini kullanır. Bunlar analiz dönemini tanımlamak için ayarlanmalıdır. Veri hacmi ile performansı dengelemek için 3 ila 6 aylık bir aralık önerilir. - Tablo ve Sütun Eşleştirme: Sorgu, standart Clarity tablo ve sütun adlarını varsayar. Kurumunuzun özel Epic yapılandırması veya sürümü farklılıklar gösterebilir. Buna göre tablo adlarını, sütun adlarını veya birleştirme koşullarını ayarlamanız gerekebilir.
- İşlem ve Durum Kodları: Sorgu,
[Reddetme İşlem Türünüz]ve[Tahsilat Durum Kodunuz]gibi yer tutucular içerir. Kurumunuz için doğru kodları bulmak amacıyla Epic sistem yöneticilerinize danışmanız veyaZC_TX_TYPEveyaZC_ACCOUNT_STATUSgibi ilgili ana dosyaları incelemeniz gerekmektedir. - Filtreleme: Daha iyi performans ve daha odaklı bir analiz için, başlangıçtaki
BaseAccountsCTE'sine filtreler ekleyin. Yaygın filtreler arasında hastane hizmet alanına göre sınırlamak içinSERV_AREA_IDveya Yatan Hasta veya Ayakta Tedavi faturalandırmasına odaklanmak içinACCOUNT_CLASS_Cbulunur.
a Örnek Sorgu sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp;