Gelir döngüsü yönetimi Veri Templateiniz
Gelir döngüsü yönetimi Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
Gelir döngüsü yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Gelir döngüsü yönetimi sürecinde gerçekleştirilen belirli olayın veya görevin adı. | ||
| Açıklama Bu öznitelik, 'Ücretler kayda alındı', 'Talep ödeme yapan kuruluşa gönderildi' veya 'Ödeme alındı' gibi gelir döngüsündeki tek bir adımı açıklar. Her etkinlik, bir hizmetin faturalandırılması ve ödemesinin tahsil edilmesi sürecinde ayrı bir kilometre taşını temsil eder. Etkinlikleri analiz etmek, Process Mining’in temelini oluşturur. Süreç haritasını görselleştirmenizi, yaygın yolları belirlemenizi, adımlar arasındaki darboğazları keşfetmenizi ve standart çalışma prosedürlerine uyumu ölçmenizi sağlar. Neden önemli? Süreç haritasındaki adımları tanımlar ve gelir döngüsündeki iş akışını görselleştirmenizi, analiz etmenizi ve iyileştirmenizi sağlar. Nereden alınır? Bu bilgi genellikle Epic Resolute’un faturalama ve talep modüllerindeki Event Loglardan, denetim izlerinden veya durum değişikliği kayıtlarından elde edilir. Örnekler Ücretler kayda alındıTalep ödeme yapan kuruluşa gönderildiÖdeme alındıHesap kapatıldı | |||
| Faturalama olayı BillingEvent | Ücret oluşturan tek bir hizmet veya ürün teslimatını tanımlayan ve temel vaka tanımlayıcısı olarak kullanılan benzersiz kimlik. | ||
| Açıklama Faturalama olayı, belirli bir faturalandırılabilir kaleme ait gelir döngüsündeki tüm etkinlikleri birbirine bağlayan temel tanımlayıcıdır. Hizmet sunulduğunda başlar, hesap tamamen ödendiğinde veya kapatıldığında sona erer. Process Mining analizinde bu öznitelik, her ücretin baştan sona izlediği yolu yeniden oluşturmak için gereklidir. Ücretlerin kayda alınması, talep gönderimi, ödeme kaydı ve ret yönetimi gibi etkinlikleri tek tek faturalama olayları için izlemenizi sağlar. Böylece süreç akışını ve farklılıklarını net biçimde görebilirsiniz. Neden önemli? Bu, her hizmetin gelir elde etme ve tahsilat yaşam döngüsünü analiz etmek için ilgili tüm süreç adımlarını birbirine bağlayan temel Vaka kimliğidir. Nereden alınır? Bu, genellikle bir hastane hesabının (HAR) veya Epic Resolute’taki belirli bir ücret oturumunun benzersiz kimliğidir. HAR veya Charge Session kayıtları gibi belirli tablolar için Epic Resolute dokümantasyonuna başvurun. Örnekler BE10098765BE20012345BE30054321 | |||
| Olay zaman damgası EventTimestamp | Belirli bir etkinliğin veya olayın gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay zaman damgası, bir etkinliğin gerçekleştiği anı kaydeder. Bu zaman bilgisi, gelir döngüsündeki olayların zamanlamasını ve sıralamasını anlamak açısından önemlidir. Analiz sırasında zaman damgaları, ücretlerin kayda alınmasındaki gecikme veya ödeme kayıt süresi gibi etkinlikler arasındaki süreleri hesaplamak için kullanılır. Darboğazları keşfetmenizi, çevrim sürelerini ölçmenizi ve süreç performansını farklı dönemlerde analiz etmenizi sağlar. Zamana dayalı KPI’ların ve Dashboardların neredeyse tamamı için doğru zaman damgaları gereklidir. Neden önemli? Bu öznitelik, gecikmeleri ve verimsizlikleri belirlemenin temelini oluşturan çevrim süreleri ve zaman aralıkları dahil, zamana dayalı tüm metrikleri hesaplamak için gereklidir. Nereden alınır? Epic Resolute’taki işlem veya olay günlüğü tablolarında, kaydedilen her etkinlikle ilişkili olarak bulunur. Alan adları genellikle Dt, DTTM veya Time gibi son ekler içerir. Örnekler 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Düzeltme nedeni AdjustmentReason | Hastanın hesap bakiyesinde yapılan elle veya otomatik düzeltmenin nedeni. | ||
| Açıklama Bu öznitelik, standart bir ödeme veya ücret dışında hesap bakiyesinin neden değiştirildiğini açıklar. Nedenler arasında ödeme yapan kuruluşlarla yapılan sözleşmelerden kaynaklanan indirimler, düşük bakiyelerin silinmesi veya kayıt hatalarının düzeltilmesi yer alabilir. Bu bilgi, 'Türüne göre hesap düzeltme hacmi' Dashboardu için gereklidir. Kuruluşlar düzeltme nedenlerini analiz ederek gelir kaybı kaynaklarını belirleyebilir, ödeme yapan kuruluşlarla yapılan sözleşmelerin etkisini anlayabilir ve faturalama sürecindeki olası verimsizlikleri veya hataları saptayabilir. Neden önemli? Hesap bakiyelerinin neden değiştirildiğini açıklayarak gelir kaybı ve faturalama doğruluğu hakkında bilgi sağlar, gereksiz borç silme işlemlerini azaltmaya yardımcı olur. Nereden alınır? Epic Resolute’un hasta muhasebesi modülündeki düzeltme kayıtlarının işlem ayrıntılarında bulunur. Örnekler Sözleşme indirimiDüşük bakiye silmeYinelenen ücret düzeltmesi | |||
| Faturalama departmanı BillingDepartment | Faturalama olayından veya etkinliğinden sorumlu departman ya da işlevsel ekip. | ||
| Açıklama Bu öznitelik, faturalama olayıyla ilişkili olan veya belirli bir etkinliği gerçekleştiren 'Yatan Hasta Faturalama', 'Ayakta Tedavi Faturalama' ya da 'Ret Yönetimi Ekibi' gibi kuruluş birimini belirtir. Bu boyut, 'Faturalama departmanı performans metrikleri' Dashboardu için önemlidir. Ret oranı veya ücretlerin kayda alınma süresi gibi temel metrikleri departmanlar arasında karşılaştırmanızı sağlar. Yönetimin yüksek performanslı departmanları belirlemesine, iyi uygulamaları standartlaştırmasına ve kaynakları etkili biçimde dağıtmasına yardımcı olur. Neden önemli? Departmanların performansını karşılaştırmanızı sağlar; iyi uygulamaları ve iyileştirme ya da ek kaynak gerektiren alanları belirlemeye yardımcı olur. Nereden alınır? Bu bilgi, Epic Resolute’taki kullanıcı kaydına, hasta hesabına veya hizmet konumuna bağlı olabilir. Örnekler Kardiyoloji faturalamaRadyoloji RCMMerkezî faturalama ofisi | |||
| Hizmet türü ServiceType | Sunulan tıbbi hizmetin kategorisi veya türü. | ||
| Açıklama Bu öznitelik, faturalandırılabilir hizmeti Radyoloji, Cerrahi, Konsültasyon veya Acil Servis Ziyareti gibi kategorilere ayırır. Finansal verilere klinik bağlam kazandırır. Gelir döngüsünü hizmet türüne göre analiz etmek, belirli klinik alanlara özgü süreç farklılıklarını ortaya çıkarabilir. Örneğin cerrahi işlemlerde ücret kaydı ve yetkilendirme gereksinimleri standart bir muayeneye göre daha karmaşık olabilir. Bu da süreçlerin farklı işlemesine ve farklı zorluklara yol açabilir. Neden önemli? Finansal verilere klinik bağlam kazandırır; farklı tıbbi hizmet türlerinin gelir döngüsü sürecini ve verimliliğini nasıl etkilediğini analiz etmeyi sağlar. Nereden alınır? Epic’te ücret işlemiyle ilişkili ücret açıklamaları ana dosyasından (CDM), hizmet hattından veya departmandan alınır. Örnekler Yatan hasta cerrahisiAyakta hasta radyolojisiAcil servis hizmetleri | |||
| Ödenmemiş bakiye OutstandingBalance | Faturalama olayı için ödeme yapan kuruluştan veya hastadan tahsil edilmesi gereken kalan tutar. | ||
| Açıklama Bu öznitelik, etkinliğin gerçekleştiği sırada belirli bir faturalama olayına ait güncel alacak bakiyesini gösterir. Vakanın yaşam döngüsü boyunca finansal durumunu yansıtır. Ödenmemiş bakiye, finansal raporlama ve 'Ödenmemiş bakiye yaşlandırma raporu' için önemlidir. Bu değeri zaman içinde ve ödeme yapan kuruluş ya da departman gibi farklı boyutlara göre analiz etmek, tahsilat çalışmaları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; tahsilat çalışmalarına öncelik vermek, nakit akışını yönetmek ve alacakları anlamak için gereklidir. Nereden alınır? Epic Resolute’taki hasta hesabı veya hastane hesabı (HAR) kaydının temel alanlarından biridir. Finansal işlemlerle güncellenen bir bakiyedir. Örnekler 1500.00250.750.00 | |||
| Ret neden kodu DenialReasonCode | Ödeme yapan kuruluşun gönderilen bir talebi neden reddettiğini gösteren standart kod. | ||
| Açıklama Ödeme yapan kuruluş bir talebi reddettiğinde, 'Kapsam dışı hizmet', 'Yinelenen talep' veya 'Ek bilgi gerekiyor' gibi ret nedenini açıklayan bir kod verir. Bu kodlar genellikle Talep Düzeltme Neden Kodları (CARC) olarak standartlaştırılır. Bu öznitelik, 'Talep ret oranları ve nedenleri' Dashboardunun temelini oluşturur. Farklı ret kodlarının sıklığını analiz etmek; yetkilendirme sorunları, kodlama hataları veya eksik ön onaylar gibi temel nedenleri belirlemeye ve hedefli iyileştirme çalışmaları başlatmaya yardımcı olur. Neden önemli? Taleplerin neden reddedildiğini doğrudan açıklar. Ret oranlarını düşürmek, gelir kaybını önlemek ve ödemeleri hızlandırmak için gereken uygulanabilir içgörüleri sağlar. Nereden alınır? Bu veri, ödeme yapan kuruluşlardan alınan talep yanıtı işlemlerinde (ANSI 835 dosyası gibi) bulunur ve Epic Resolute’un talep yönetimi modülünde saklanır. Örnekler CO-16: Talep/hizmet bilgileri eksikOA-18: Yinelenen talep/hizmetPR-96: Kapsam dışı ücret(ler) | |||
| Sorumlu kullanıcı ResponsibleUser | Etkinliği gerçekleştiren kullanıcının veya çalışanın kimliği. | ||
| Açıklama Bu öznitelik, gelir döngüsündeki belirli bir görevi tamamlamaktan sorumlu kişinin kullanıcı kimliğini, adını veya çalışan numarasını kaydeder. Bu kişi ücretleri giren klinisyen, talebi gönderen faturalama görevlisi veya ret için takip yapan tahsilat görevlisi olabilir. Kullanıcı bazında analiz yapmak, en iyi performans gösterenleri belirlemeye, eğitim ihtiyaçlarını saptamaya ve iş yükünün nasıl dağıldığını anlamaya yardımcı olur. Performans yönetimi ve belirli kişilerle veya rollerle ilişkili süreç sapmalarını incelemek için önemlidir. Neden önemli? Kişi veya rol bazında performans analizi yapmanızı sağlar; eğitim fırsatlarını, iş yükü dengesizliklerini ve kaynaklarla ilgili darboğazları belirlemeye yardımcı olur. Nereden alınır? Genellikle Epic Resolute’taki denetim izlerinde veya işlem günlüklerinde bulunur ve çoğu zaman bir kullanıcı ana veri tablosuna (ör. EMP kaydı) bağlıdır. Örnekler j.doebsmith123User7890 | |||
| Düzeltilmiş tutar AdjustedAmount | Bir düzeltme işleminin parasal değeri. | ||
| Açıklama Bu alan, hesap düzeltmesinin belirli tutarını kaydeder. Hesap bakiyesine alacak veya borç olarak yansıyan değer pozitif ya da negatif olabilir. Bu tutar, Türüne Göre Hesap Düzeltme Hacmi Dashboardunun temel metriğidir. Tutarı düzeltme nedenine göre toplamak, farklı düzeltme türlerinin finansal etkisini net biçimde gösterir. Örneğin sözleşme yükümlülükleri nedeniyle gelirden ne kadar vazgeçildiğini ve düzeltilebilir hatalar yüzünden ne kadar kayıp yaşandığını ortaya koyar. Neden önemli? Hesap düzeltmelerinin finansal etkisini ölçer; gelir kaybını ve faturalandırma hatalarının maliyetini hesaplamayı sağlar. Nereden alınır? Epic Resolute içindeki finansal işlem ayrıntısı tablolarında, düzeltme türündeki işlemlerle ilişkili olarak bulunur. Örnekler -1250.45-50.0025.10 | |||
| Hasta kimliği PatientId | Hizmeti alan hastaya ait benzersiz tanımlayıcı. | ||
| Açıklama Bu öznitelik, hastanın Tıbbi Kayıt Numarası (MRN) veya başka bir benzersiz tanımlayıcısıdır. Finansal faturalandırma olayını belirli bir kişiyle ilişkilendirir. Hasta gizliliğini korumak için genellikle birincil analiz boyutu olarak kullanılmasa da veri doğrulaması açısından gereklidir. Ayrıca tek bir hastaya ait tüm faturalandırma olaylarını bir araya getirerek hastanın genel finansal sürecini anlamaya yardımcı olur. Klinik süreç verileriyle olası entegrasyonlar için de önemlidir. Neden önemli? Finansal verileri belirli bir hastayla ilişkilendirerek veri doğrulamasını ve hastanın tüm sürecinin daha geniş kapsamlı analizini mümkün kılar. Gizlilik kaygıları nedeniyle bu veriler dikkatle ele alınmalıdır. Nereden alınır? Epic genelinde bulunan temel bir tanımlayıcıdır; hastanın kayıt ve hesap bilgileriyle ilişkilidir. Örnekler MRN-1234567MRN-8765432MRN-5551234 | |||
| Kaynak sistem SourceSystem | Verinin geldiği bilgi sistemi. | ||
| Açıklama Bu öznitelik, kaydın kaynak sistemini belirtir. Bu kullanımda kaynak sistem Epic Resolute’tur. Birden fazla entegre sistemin bulunduğu ortamlarda bu alan, verilerin hangi sistemden geldiğini ayırt etmeye yardımcı olur. Tek sistemli bir görünümde gereksiz gibi görünse de veri yönetişimi ve ölçeklenebilirlik açısından iyi bir uygulamadır. Örneğin ayrı bir tahsilat platformu gibi başka sistemlerden veri eklendiğinde kaynakların net biçimde ayırt edilmesini sağlar. Neden önemli? Verinin kaynağını netleştirerek veri soy ağacı ve bağlam bilgisi sağlar. Bu bilgiler, veri yönetişimi ve sorun giderme açısından önemlidir. Nereden alınır? Bu, genellikle veri çıkarma ve dönüştürme sırasında Veri Seti’nin kaynağını belirtmek için eklenen sabit bir değerdir. Örnekler Epic ResoluteEpicResolute_V2023 | |||
| Ödeme vadesi PaymentDueDate | Faturalanan hizmetin ödemesinin yapılmasının beklendiği son tarih. | ||
| Açıklama Bu öznitelik, faturada belirtilen veya ödeme yapan kuruluşla yapılan sözleşmede belirlenen ödeme son tarihini gösterir. Zamanında ödemeleri ölçmek için bir referans noktası sağlar. Ödeme vadesi, Vadesi Geçmiş Bakiye Yaşlandırma Raporunu hazırlamak için gereklidir. Açık bakiyelerin vadesi geçtikten sonra geçen süreyi hesaplamak için geçerli tarih ile vade tarihi karşılaştırılır. Böylece alacaklar yaşlandırma aralıklarına (ör. 0-30 gün, vadesi 31-60 gün geçmiş) ayrılır ve tahsilat çalışmaları en uzun süredir ödenmemiş hesaplara öncelik verecek şekilde planlanabilir. Neden önemli? Alacakların yaşlandırma analizine temel oluşturur. Tahsilatlara öncelik vermek ve ödenmemiş faturalardan kaynaklanan finansal riski yönetmek için önemlidir. Nereden alınır? Bu tarih genellikle fatura tarihi ve Epic’teki ödeme yapan kuruluş sözleşmesinde ya da hasta hesabı bilgilerinde kayıtlı ödeme koşulları kullanılarak hesaplanır. Örnekler 2023-05-302023-06-152023-07-01 | |||
| Ödeme yapan kuruluşun adı PayerName | Ödemeden sorumlu sigorta şirketinin, kamu kurumunun veya başka bir tarafın adı. | ||
| Açıklama Bu öznitelik, faturalama olayıyla ilişkili temel ödeme yapan kuruluşu belirtir. Örneğin 'Blue Cross Blue Shield', 'Medicare' veya 'Aetna'. Hastanın kendi ödemesini yaptığı durumlarda hasta bilgisi yer alabilir. Süreci ödeme yapan kuruluşa göre bölümlere ayırmak etkili bir analiz yöntemidir. Bu analiz, bazı kuruluşlarda ret oranlarının daha yüksek, ödeme döngülerinin daha uzun veya gerekliliklerin daha karmaşık olduğunu gösterebilir. Bu içgörü, verimliliği ve ödeme hızını artırmak için faturalama stratejilerini ilgili kuruluşa göre uyarlamanızı sağlar. Neden önemli? Ödeme yapan kuruluş bazında performans analizi yapmanızı sağlar. Ret oranlarının yüksek veya ödeme döngülerinin yavaş olduğu kuruluşları belirleyerek hedefli takip stratejileri geliştirmenize yardımcı olur. Nereden alınır? Bu bilgiler, Epic Resolute içindeki hastane hesabına (HAR) bağlı hasta kapsamı ayrıntılarının bir parçasıdır. Örnekler Medicare B BölümüUnitedHealthcareAetna PPO | |||
| Olay bitiş zamanı EventEndTime | Bir etkinliğin tamamlandığı zamanı gösteren zaman damgası; etkinlik süresini hesaplamak için kullanılır. | ||
| Açıklama Bu öznitelik, bir etkinliğin tamamlanma zamanını kaydeder. Başlangıç zamanının bitiş zamanına eşit olduğu anlık etkinliklerin yanı sıra, ret takibi için yapılan telefon görüşmesi gibi ölçülebilir süresi olan bazı görevler de vardır. Bitiş zamanı mevcutsa etkinliğin işlem süresi doğrudan hesaplanabilir (Bitiş zamanı - Başlangıç zamanı). Bu yöntem, adımlar arasındaki bekleme süresini de hesaba kattığı için süreyi bir sonraki etkinliğin başlangıç zamanından tahmin etmekten daha doğrudur. İşlem süresi özniteliğinin hesaplanmasında temel bir bileşendir. Neden önemli? Her etkinliğin tamamlanma süresini hassas biçimde hesaplamayı sağlar. Verimsiz görevleri belirlemek ve kaynak verimliliğini ölçmek için önemlidir. Nereden alınır? Görev başlangıç ve bitiş zamanlarını izleyen bazı Epic Resolute modüllerinde, örneğin iş kuyruğu veya etkinlik yönetimi günlüklerinde bulunabilir. Çoğu zaman açıkça izlenmez. Örnekler 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Otomatik mi IsAutomated | Etkinliğin sistem veya otomatik bir süreç tarafından gerçekleştirilip gerçekleştirilmediğini belirten mantıksal bir işaret. | ||
| Açıklama Bu işaret, otomatik talep oluşturma veya uygunluk kontrolleri gibi sistem tarafından otomatik yürütülen görevleri kullanıcıların elle gerçekleştirdiği görevlerden ayırır. Bu özniteliği analiz etmek, süreçteki otomasyon düzeyini anlamaya yardımcı olur. Otomatik ve manuel etkinliklerin verimliliği ile hata oranlarını karşılaştırmak, yeni otomasyon fırsatlarını belirlemek ve mevcut botların ya da sistem kurallarının performansını izlemek için kullanılabilir. Neden önemli? Sistem tarafından yürütülen etkinlikleri kullanıcıların gerçekleştirdiği etkinliklerden ayırır. Otomasyonun etkisini değerlendirmek ve yeni otomasyon fırsatlarını belirlemek için önemlidir. Nereden alınır? Genellikle etkinliğin sorumlu kullanıcısının bir sistem veya hizmet hesabı olup olmadığı kontrol edilerek ya da otomatik olduğu bilinen belirli etkinlik adları işaretlenerek belirlenir. Örnekler truefalse | |||
| Son veri güncellemesi LastDataUpdate | Bu olaya ait verilerin kaynak sistemden en son yenilendiği veya çıkarıldığı zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, verilerin güncelliğini gösterir. Kaydın Epic Resolute’tan Process Mining Veri Seti’ne en son ne zaman aktarıldığını belirtir. Analizin ne kadar güncel olduğunu anlamak ve verileri doğrulamak açısından önemlidir. Kullanıcıların mevcut en güncel bilgileri inceleyip incelemediğini anlamasına yardımcı olur ve veri yenileme döngülerinin yönetiminde önem taşır. Neden önemli? Kullanıcıların analiz ettikleri verilerin güncelliğini anlamasını sağlar. Bu, doğru ve güncel iş kararları almak açısından önemlidir. 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 | |||
| Talep kimliği ClaimId | Ödeme yapan kuruluşa gönderilen sigorta talebine atanan benzersiz tanımlayıcı. | ||
| Açıklama Bu öznitelik, ödeme yapan kuruluşa gönderilen talep formunun (ör. CMS-1500 veya UB-04) kimliğidir. Hizmet yeniden faturalandırılır veya itiraza konu olursa tek bir faturalandırma olayı birden fazla talep içerebilir. Talep kimliğine göre izleme, talep gönderimi ve ret yönetimi alt süreçlerini ayrıntılı analiz etmeye yardımcı olur. İlk taleple aynı hizmet için daha sonra yeniden gönderilen talebe ilişkin etkinlikleri birbirinden ayırmayı sağlar. Neden önemli? Her talep gönderiminin yaşam döngüsünü izlemek için ayrıntılı bir tanımlayıcı sağlar. Yeniden gönderimleri ve itirazları analiz etmek açısından önemlidir. Nereden alınır? Talep oluşturulduğunda Epic Resolute’un talep yönetimi modülü tarafından üretilir ve talep veri tablolarında saklanır. Örnekler CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Toplam gelir döngüsü süresi TotalRevenueCycleTime | İlk hizmet olayından son ödemeye veya hesabın kapatılmasına kadar geçen toplam süre. | ||
| Açıklama Bu vaka düzeyindeki KPI, tek bir faturalandırma olayı için gelir döngüsünün baştan sona ne kadar sürdüğünü ölçer. Genellikle Hizmet sunuldu etkinliği ile son Ödeme alındı veya Hesap kapatıldı etkinliği arasındaki süre hesaplanarak bulunur. Bu üst düzey metrik, RCM sürecinin genel verimliliğini bütünsel olarak gösterir. KPI’ı zaman içinde izlemek, süreç iyileştirme çalışmalarının etkisini ölçmeye yardımcı olur ve nakde dönüşüm hızını gösteren temel bir ölçüt sunar. Neden önemli? Süreç verimliliğini baştan sona üst düzeyde gösterir ve bir hizmetin ne kadar sürede nakde dönüştüğünü doğrudan ölçer. Nereden alınır? Bu metrik, her vakanın ilk ve son olayları filtrelenip aralarındaki süre hesaplanarak Process Mining aracında oluşturulur. Örnekler 259200038880005184000 | |||
Gelir döngüsü yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hesap kapatıldı | Bu son etkinlik, faturalama olayının ödenmemiş bakiyesinin sıfıra indiğini ve bekleyen başka bir işlem kalmadığını gösterir. Bakiye, ödemenin tamamlanması, düzeltmeler veya borcun silinmesi sonucunda sıfırlanabilir. | ||
| Neden önemli? Bu olay, faturalama olayına ait gelir döngüsünün başarıyla tamamlandığını gösterir. Hizmetin sunulmasından hesabın kapanmasına kadar geçen toplam süre, genel süreç verimliliğini ölçen önemli bir KPI’dır. Nereden alınır? Bu olay genellikle mevcut verilerden çıkarılır. Faturalama olayına ait hesap bakiyesinin sıfırlandığı ve sıfır kaldığı zaman belirlenir. Kaydedin Hesap bakiyesinin kümülatif toplamı hesaplanarak ve bakiyeyi sıfırlayan son işlemin zaman damgası belirlenerek çıkarılır. Olay türü inferred | |||
| Hizmet sunuldu | Bu etkinlik, hastaya klinik hizmetin sunulduğu ve faturalama olayının başladığı noktayı gösterir. Genellikle klinisyen bir muayene veya işlem kaydını onayladığında Epic EHR (EpicCare) üzerinden kaydedilir. | ||
| Neden önemli? Bu, gelir döngüsünün temel başlangıç olayıdır. Bu noktadan ücretlerin kayda alınmasına kadar geçen süreyi analiz etmek, faturalamanın başlamasındaki gecikmeleri ve olası gelir kaybını belirlemek açısından önemlidir. Nereden alınır? Bu olay genellikle faturalama hesabına bağlı klinik modüllerdeki hizmet veya muayene zaman damgalarından çıkarılır. Ücret işlemindeki hizmet tarihi temel veri noktasıdır. Kaydedin Faturalama olayına ait ilk ücret işlemiyle ilişkili hizmet tarihinden çıkarılır. Olay türü inferred | |||
| Ödeme alındı | Ödeme yapan kuruluştan veya hastadan ödeme alınmasını ifade eder. Bu olay genellikle elektronik ödeme bildirimi (ERA) yüklendiğinde veya sisteme elle çek girişi yapıldığında kaydedilir. | ||
| Neden önemli? Bu etkinlik, gelirin tahsil edilmeye başladığını gösteren önemli bir kilometre taşıdır. Talebin gönderilmesiyle ödemenin alınması arasındaki süre, alacak hesaplarının performansını ölçen temel göstergelerden biridir. Nereden alınır? Resolute’ta ödeme işlemi olarak açıkça kaydedilir. Bu işlemler tarih, kaynak ve tutar bilgileriyle günlüğe alınır; çoğu zaman tek tek ücretlere işlenmeden önce kaydedilir. Kaydedin Ödeme işlemlerini finansal işlem günlüğünden alın. Bu işlemler genellikle belirli işlem türleriyle tanımlanır. Olay türü explicit | |||
| Ödeme hesaba işlendi | Alınan ödemenin hastanın hesabındaki belirli ücretlere uygulandığı veya dağıtıldığı olaydır. Bu işlem, faturalama olayının ödenmemiş bakiyesini azaltır. | ||
| Neden önemli? Ödeme kayıtlarının verimli biçimde işlenmesi, hesap bakiyelerinin doğru tutulması ve faturalama olaylarının kapatılması için önemlidir. Ayrıca ikincil faturalama veya tahsilat için kalan bakiyelerin doğru belirlenmesini sağlar. Nereden alınır? Resolute’ta açıkça kaydedilen bir işlemdir. Ödeme kaydı, bir ödeme işlemini bir veya daha fazla ücret işlemine bağlar ve işlem ayrıntısı tablolarında tutulur. Kaydedin Ödemeyi bir ücrete uygulayan işlem kaydını alın. Bu kayıt, belirli işlem türleriyle tanımlanabilir. Olay türü explicit | |||
| Talep ödeme yapan kuruluş tarafından reddedildi | Ödeme yapan kuruluştan talebin reddedildiğine ilişkin bildirimin alınmasını ifade eder. Epic elektronik ödeme bildirimini (835 dosyası) işlediğinde veya kullanıcı ret kaydını elle girdiğinde kaydedilir. | ||
| Neden önemli? Bu etkinlik, önemli bir yeniden çalışma döngüsünü başlatır. Ret nedenlerini ve sayılarını analiz etmek, temel nedenleri belirlemek, ilk gönderimde ödeme oranını artırmak ve tahsilat gecikmelerini azaltmak için gereklidir. Nereden alınır? Talep üzerinde işlem veya durum güncellemesi olarak açıkça kaydedilir. Neden kodları da dahil olmak üzere ret bilgileri genellikle elektronik olarak alınır ve hesaba işlenir. Kaydedin Reddedildiğini gösteren belirli işlem türlerine veya talep durumu güncellemelerine göre filtreleyin. Olay türü explicit | |||
| Talep ödeme yapan kuruluşa gönderildi | Bu olay, talebin değerlendirilmek üzere sigorta kuruluşuna resmen gönderildiğini gösterir. Epic’te elektronik talep dosyası takas merkezine veya ödeme yapan kuruluşa iletildiğinde kaydedilen, izlenebilir bir olaydır. | ||
| Neden önemli? Bu kilometre taşı önemlidir; çünkü ödeme yapan kuruluşun ödeme süresini başlatır. Bu adımı analiz etmek, taleplerin iletim sürecinin verimliliğini ölçmeye yardımcı olur ve Faturanın ödeme yapan kuruluşa iletilme süresi KPI’ını destekler. Nereden alınır? Resolute’ta açıkça kaydedilen bir olaydır. Talep kaydında gönderim durumu ve gönderim zamanını belirten bir zaman damgası bulunur. Kaydedin Talep durumu 'Submitted' veya 'Transmitted' olarak değiştiğinde kaydedilen zaman damgasını alın. Olay türü explicit | |||
| Ücretler kayda alındı | Bu etkinlik, sunulan hizmetler için faturalandırılabilir ücretlerin resmî olarak kaydedilmesini ifade eder. Epic’te bu, genellikle hastanın hesabına işlenen açık bir işlemdir; klinik işlemlerden otomatik olarak oluşturulabilir veya elle girilebilir. | ||
| Neden önemli? Bu, ilk önemli kilometre taşıdır. Ücretlerin kayda alınma hızını ve doğruluğunu ölçmek, faturalama sürecini hızlandırmaya ve sunulan tüm hizmetlerin faturalandırılmasını sağlamaya yardımcı olur. Nereden alınır? Resolute işlem günlüklerinde açıkça kaydedilir. Her ücret; kayıt tarihi, hizmet tarihi ve tutarı olan ayrı bir girdidir. Bu bilgiler genellikle ARPB_TRANSACTIONS gibi tablolarda bulunur. Kaydedin Ücret kaydı işlemlerini sistemin finansal işlem günlüğünden alın. Olay türü explicit | |||
| Bakiye tahsilata gönderildi | Ödenmemiş hesap bakiyesinin kurum içi veya harici bir tahsilat sürecine aktarıldığı noktayı gösterir. Bu, genellikle hesap veya faturalama olayındaki açık bir durum değişikliğidir. | ||
| Neden önemli? Bu etkinlik, ödenmemiş bakiyelerin tahsil edilmesine yönelik son aşamayı başlatır. Tahsilat sürecinin başarı oranını ve çevrim süresini izlemek, tahsil edilemeyen borçları azaltmak açısından önemlidir. Nereden alınır? Bu genellikle açıkça kaydedilen bir olaydır. Epic’te hesapları tahsilat kuruluşlarına aktarma işlevleri bulunur; bu işlem hesapta bir günlük girdisi veya durum değişikliği oluşturur. Kaydedin Hesabın bir tahsilat kuruluşuna devredildiğini gösteren durum değişikliğini veya işlemi belirleyin. Olay türü explicit | |||
| Hesap düzeltmesi yapıldı | Bu etkinlik, sözleşme düzeltmesi, düşük bakiye silme veya iyi niyet indirimi gibi hesap bakiyesini değiştiren ödeme dışı bir işlemi ifade eder. Belirli bir işlem türü olarak kaydedilir. | ||
| Neden önemli? Düzeltmeleri analiz etmek, gelir kaybının kaynaklarını belirlemek açısından önemlidir. Bazı düzeltme türlerinin sayısının yüksek olması ücret tarifeleri, sözleşmeler veya iç politikalarla ilgili sorunlara işaret edebilir. Nereden alınır? Resolute finansal günlüklerinde düzeltme işlemleri olarak açıkça kaydedilir. Her düzeltmeyle ilişkili belirli bir tür veya neden kodu bulunur. Kaydedin Finansal düzeltmelere veya borç silme işlemlerine karşılık gelen işlem türlerine göre filtreleyin. Olay türü explicit | |||
| Ret için takip süreci başlatıldı | Bu etkinlik, reddedilen bir talebi inceleyip çözüme kavuşturmak için yürütülen iç sürecin başlangıcını gösterir. Genellikle kullanıcı bir iş kuyruğunda reddedilen talebi üstlendiğinde veya talebin durumunu değiştirdiğinde kaydedilir. | ||
| Neden önemli? Bu adımı izlemek, ret yönetimi ekibinin ne kadar hızlı yanıt verdiğini ölçmeye yardımcı olur. Ret ile takip sürecinin başlaması arasındaki gecikmeler gelir döngüsünü gereksiz yere uzatabilir. Nereden alınır? Bu olay genellikle Epic iş kuyruklarındaki talep durumu veya atama geçmişindeki değişikliklerden çıkarılır. Örneğin talebin durumu 'Denied' iken 'In Review' olarak değişebilir. Kaydedin Talep durumundaki değişiklikten veya kullanıcının ret üzerinde çalışmaya başladığını gösteren denetim günlüğü girdisinden çıkarın. Olay türü inferred | |||
| Talep oluşturuldu | Bu etkinlik, kayda alınan ücretlere dayanarak sistemde resmî bir talep veya fatura oluşturulduğunu gösterir. Talebin ödeme yapan kuruluşa ya da hastaya gönderilmesinden önceki hazırlık adımıdır. | ||
| Neden önemli? Talep oluşturma sürecini izlemek, ücretlerin kayda alınmasıyla gönderime hazırlanması arasındaki gecikmeleri belirlemeye yardımcı olur. Bu önemli iç adım, faturalamanın genel zamanlamasını etkileyebilir. Nereden alınır? Bu işlem genellikle bir faturalama veya talep oluşturma toplu işi çalıştığında günlüğe kaydedilir. Sistem, belirli bir hesap için talep dosyası (örneğin 837 dosyası) oluşturulduğunda zaman damgası kaydeder. Kaydedin Talebin derlendiğini ve gönderime hazır olduğunu gösteren günlük girdilerini veya durum değişikliklerini belirleyin. Olay türü explicit | |||
| Talep yeniden gönderildi | Bu olay, reddedilen talep düzeltildikten sonra ödeme yapan kuruluşa yeniden gönderildiğinde gerçekleşir. İlk taleple bağlantılı, ayrı bir gönderim olayıdır. | ||
| Neden önemli? Bu, yeniden çalışma döngüsünün önemli bir parçasıdır. Yeniden gönderim süresini ve yeniden gönderilen taleplerin başarı oranını ölçmek, ret çözüm sürecinin ne kadar etkili olduğunu anlamak açısından önemlidir. Nereden alınır? İlk gönderime benzer, açıkça kaydedilen bir olaydır; ancak genellikle yeniden gönderim olarak işaretlenir. Talep kaydında yeni bir gönderim zaman damgası bulunur ve yeniden gönderim kodu yer alabilir. Kaydedin Düzeltme veya yeniden gönderim olarak işaretlenen talep gönderiminin zaman damgasını alın. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Veritabanı bağlantısını kurun: Epic Clarity veritabanı için salt okunur kimlik bilgilerini alın. Veritabanı sunucusuna bağlanmak için DBeaver veya Microsoft SQL Server Management Studio gibi standart bir SQL istemcisi kullanın.
- Temel tabloları belirleyin: Bu veri çıkarma işlemi için temel tablolar arasında vaka bilgileri için
HSP_ACCOUNT, finansal olaylar içinHSP_TRANSACTIONS, talep durumu içinCLP_CLAIM_INFOve ödeme kaydı ayrıntıları içinF_ARHB_TX_SET_POST_HXbulunur. Kullanıcı ayrıntıları içinCLARITY_EMPgibi ana dosyaları da birleştirin. - Kapsamı belirleyin: Sorguyu yazmadan önce analiz kapsamınızı belirleyin. Genellikle 3 ila 6 aylık belirli bir tarih aralığı seçin ve dahil etmek ya da hariç tutmak istediğiniz hastane hizmet alanlarını (
SERV_AREA_ID) veya hesap sınıflarını belirleyin. - SQL sorgusunu hazırlayın: Önce belirlediğiniz kapsama giren
HSP_ACCOUNT_IDdeğerlerini seçmek için Ortak Tablo İfadesi (CTE) kullanan bir SQL sorgusu oluşturun. Bu değerler, faturalandırma olaylarının temel kümesini oluşturur. - Etkinlik sorgularını ayrı ayrı birleştirin: Gerekli 12 etkinliğin her biri için ilgili tablolardan veri alan ayrı bir
SELECTifadesi yazın. Yalnızca hedeflediğiniz hesapları analiz ettiğinizden emin olmak için başlangıçtaki CTE’ye yeniden bağlanın. - Sorguları UNION ALL ile birleştirin: Her etkinlik sorgusunun sonuçlarını tek bir Event Logunda birleştirmek için
UNION ALLişleçini kullanın. Bu işlem, her sorgunun satırlarını alt alta ekler. - Standart şemaya eşleyin: Her
SELECTifadesinde sütun adlarını gerekli ProcessMind şemasıyla eşleşecek şekilde takma adlarla belirtin:BillingEvent,ActivityName,EventTimestamp,ResponsibleUservb. Belirli bir etkinlik için geçerli olmayan özniteliklerdeNULLkullanın. - Sorguyu çalıştırıp iyileştirin: Sorgunun tamamını Clarity veritabanında çalıştırın. Tabloların boyutu nedeniyle işlem uzun sürebilir. Performans sorunu yaşarsanız tarih aralığını daraltın veya başlangıçtaki CTE’ye daha belirgin filtreler ekleyin.
- Çıktıyı inceleyin: Sorgu tamamlandığında çıktının ilk birkaç yüz satırını kontrol edin. Tüm sütunların bulunduğunu, zaman damgalarının tutarlı biçimde gösterildiğini ve farklı
ActivityNamedeğerlerinin beklendiği gibi geldiğini doğrulayın. - CSV olarak dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden CSV dosyasına aktarın. Dosyanın UTF-8 kodlaması kullandığından ve doğru sütun adlarını içeren bir başlık satırına sahip olduğundan emin olun.
- Yüklemeye hazırlanın: ProcessMind’e yüklemeden önce biçimlendirme hatası olmadığını doğrulamak için CSV dosyasını açın. Örneğin
YYYY-MM-DD HH:MI:SSbiçiminde, zaman damgalarının tutarlı olduğunu kontrol edin. Dosya artık içe aktarılmaya hazırdır.
Yapılandırma
- Veritabanı bağlantısı: Epic Clarity veritabanına erişimi olan salt okunur bir kullanıcı hesabı gerekir.
- Tarih aralığı parametreleri: Sağlanan sorguda
@StartDateve@EndDatedeğişkenleri kullanılır. Analiz dönemini belirlemek için bu değişkenlere değer atayın. Veri hacmi ile performans arasında denge kurmak için 3 ila 6 aylık bir aralık önerilir. - Tablo ve sütun haritalama: Sorgu, standart Clarity tablo ve sütun adlarını varsayar. Kuruluşunuzun Epic yapılandırması veya sürümü farklılık gösterebilir. Tablo adlarını, sütun adlarını ya da birleştirme koşullarını buna göre uyarlamanız gerekebilir.
- İşlem ve durum kodları: Sorguda
[Your Denial Tx Type]ve[Your Collections Status Code]gibi yer tutucular bulunur. Kullandığınız sistem için doğru kodları bulmak üzere Epic sistem yöneticilerinize danışın veyaZC_TX_TYPEveZC_ACCOUNT_STATUSgibi ilgili ana dosyaları inceleyin. - Filtreleme: Performansı artırmak ve analizi odaklamak için başlangıçtaki
BaseAccountsCTE’sine filtreler ekleyin. Yaygın filtreler arasında hastane hizmet alanını sınırlamak içinSERV_AREA_IDve yatan ya da ayakta hasta 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
- Hesap, ücret, talep, ret, ödeme, düzeltme, tahsilat ve kapanış geçmişi için gereken kaynak tablolar ve görünümler dahil olmak üzere Epic Clarity gelir döngüsü veri kümesine yetkili erişiminiz olduğunu doğrulayın. Epic kuruluşlarında tablo kullanılabilirliği ve sütun adları farklılık gösterebilir. Bu nedenle sorgudaki her yer tutucuyu ortamınızdaki ilgili Clarity nesnesiyle eşleyin.
- Veri çıkarma dönemini [Start date parameter] ve [End date parameter] kullanarak belirleyin. Başlangıçta üç ila altı aylık bir dönem seçin; sorgu performansını ve olayların eksiksizliğini doğruladıktan sonra aralığı genişletin.
- BillingEvent eşlemesini belirleyin. Sorgu, kullanılabilir olduğunda varsayılan vaka tanımlayıcısı olarak HSP_ACCOUNT.HSP_ACCOUNT_ID değerini kullanır. Kuruluşunuz faturalandırma olayını ücret, talep veya karşılaşma düzeyinde tanımlıyorsa eşlemeyi onaylanmış tanımlayıcıyla değiştirin ve bu tanımlayıcıyı tüm etkinlik kaynaklarında tutarlı biçimde kullanın.
- Her kaynak etkinliği yetkili bir zaman damgası ve kaynak özniteliğiyle eşleyin. Hizmet sunuldu etkinliği için belgelenmiş hizmet veya karşılaşma tamamlanma zaman damgasını kullanın. Ücretler kaydedildi etkinliği için ücret kayıt zaman damgasını kullanın. Talep oluşturuldu ve Talep ödeme yapan kuruluşa gönderildi etkinlikleri için ilgili talep yaşam döngüsü zaman damgalarını kullanın. Ret, takip, yeniden gönderim, ödeme, düzeltme, tahsilat ve kapanış etkinliklerinde belgelenmiş işlem veya durum zaman damgalarını kullanın.
- Sorgudaki köşeli parantez içindeki tüm kaynak yer tutucularını değiştirin. Bunlara [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] ve [Your account closure source table] dahildir. Belgelenmemiş işlem kodlarını kullanmayın. Epic raporlama ekibinizin onayladığı işlem veya durum değerlerini kullanın.
- Sorguyu kuruluşunuzun onayladığı SQL istemcisinde veya raporlama platformunda çalıştırın. On iki etkinlik etiketinin tamamının ayrı satırlar olarak döndürüldüğünü doğrulayın. ProcessMind, bakiyelerden, durumlardan veya olay sıralamasından eksik yaşam döngüsü olaylarını çıkarmaz.
- Çıktı şemasını inceleyin. Sonuçta BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance ve ServiceType alanları bulunmalıdır. Zaman damgalarını saat dilimi veya yerel saat bilgisiyle birlikte koruyun. İzin veriliyorsa kaynak tanımlayıcılarını dahili denetim çıktısında saklayın.
- Her BillingEvent içindeki kronolojik sıralamayı, yinelenen kayıtları, boş değer oranlarını, etkinlik sayılarını ve kaynak sistem raporlarıyla mutabakatı doğrulayın. Dönemden önce başlayan veya dönemden sonra biten vakaları anlamak için gereken dönem dışı olayları inceleyin.
- Sonucu, ProcessMind’in desteklediği ayrılmış bir dosya veya veritabanı bağlantısı olarak dışa aktarın. Her olay için bir satır, tutarlı sütun adları ve zaman damgası biçimi kullanın. UTF-8 kodlamasını tercih edin; birleştirilmiş hücreler veya sunum amaçlı toplamlar eklemeyin. Yükleme sırasında BillingEvent’i vaka tanımlayıcısı, ActivityName’i etkinlik ve EventTimestamp’i olay zaman damgası olarak ayarlayın.
Yapılandırma
- Kaynak haritalaması: Epic Clarity kurulumları farklılık gösterir. Köşeli parantez içindeki her kaynak nesnesi ve sütun yer tutucusunu, ortamınızda belgelenmiş bir tablo, görünüm veya onaylı raporlama katmanıyla değiştirin. Başka bir Epic kurulumunda yaygın diye bir tablo ya da alanın sizin ortamınızda da bulunduğunu varsaymayın.
- Vaka tanımlayıcısı: Varsayılan sorgu eşlemesi HSP_ACCOUNT.HSP_ACCOUNT_ID kullanır. Kuruluşunuzun BillingEvent değerini hesap, karşılaşma, talep, ücret veya onaylanmış başka bir iş anahtarı olarak tanımlayıp tanımlamadığını doğrulayın.
- Tarih aralığı: Üç ila altı ayla başlayın. Vakalar raporlama döneminden önce başlayabiliyorsa geriye dönük bir süre, talepler, retler, ödemeler veya kapanış hizmet tarihinden sonra gerçekleşebiliyorsa takip dönemi ekleyin.
- Etkinlik zaman damgaları: Her etkinlik için tek bir yetkili zaman damgası belirleyin. Belgelenmiş kaynak sistem etkinlik zaman damgası olmadığı sürece, gerçek iş etkinliğinin zamanı yerine veri çıkarma, dosya yükleme veya mevcut durum zamanını kullanmayın.
- Filtreler: [Şirket kodu filtresi], [Belge türü filtresi], [Departman filtresi], ödeyici, hizmet bölgesi ve hesap sınıfı filtrelerini yalnızca tanımları belgelenmiş ve analiz için gerekli olduğunda uygulayın. Filtreleri tüm UNION ALL dallarında tutarlı kullanın.
- İşlem ve durum eşlemesi: Ücret kaydı, talep oluşturma, talep gönderme, ret, takip, yeniden gönderim, ödeme alma, ödeme kaydı, düzeltme, tahsilat ve kapanış için kuruluşunuzca onaylanmış değerleri yapılandırın. Epic işlem değerleri ve kaynak yapıları kurulumdan kuruluma değiştiği için sorguda bilerek yer tutucular kullanılmıştır.
- NULL değerlerin işlenmesi: Bir etkinlik için geçerli olmayan özniteliklerde NULL değerini koruyun. Eksik ret nedenlerini, düzeltme nedenlerini, kullanıcıları, departmanları veya hizmet türlerini uydurma değerlerle değiştirmeyin.
- Performans: HSP_ACCOUNT ile birleştirmeden önce kaynak satırlarını dizinlenmiş tarih sütunları ve onaylı kuruluş filtreleriyle sınırlayın. Koşullarda dizinlenmiş zaman damgası sütunlarına işlev uygulamayın. Ham geçmiş verisi büyükse her kaynak etkinliği onaylı bir raporlama görünümünde somutlaştırmayı değerlendirin.
- Tekilleştirme: Belgelenmiş bir kural olmadan yinelenen etkinlikleri kaldırmayın. Bir BillingEvent için birden fazla ödeme, düzeltme, gönderim veya durum değişikliği geçerli etkinlikler olabilir.
- Ön koşullar: Gerekli erişim; Epic Clarity raporlama yetkisini, gelir döngüsü ve hesap geçmişi verilerine erişimi, onaylı bir SQL çalıştırma ortamını ve korunan sağlık bilgilerinin kullanımı için kuruluş onayını içerebilir. Talep, ödeme bildirimi, iş kuyruğu, tahsilat ve kapanış geçmişinin kullanılabilirliği, lisanslanan ve uygulanan Epic modüllerine ve arayüzlerine bağlıdır.
a Örnek sorgu sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Başlamaya hazır mısınız?
Doğru verilerle gelir döngüsü yönetimi sürecinizin potansiyelini keşfedin. Verimliliği ve finansal performansı artırmak için bugün ilk adımı atın.
Verimliliği artırın: Gelir döngüsü yönetiminizi şimdi optimize edin
Epic Resolute’taki RCM verimsizliklerini belirleyin, çevrim süresini %30 azaltın.
Kredi kartı gerekmez, optimizasyona bugün başlayın.