Gelir Döngüsü Yönetimi Veri Şablonunuz
Gelir Döngüsü Yönetimi Veri Şablonunuz
- Kapsamlı analiz için önerilen veri öznitelikleri
- Etkili Bir Şekilde Takip Edilecek Temel Süreç Aktiviteleri
- Waystar'dan veri çekme için pratik rehberlik
Gelir Döngüsü Yönetimi Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Billing Event BillingEvent | Gelir döngüsü süreci için vaka görevi gören, bir ücret üreten tek bir hizmet veya ürün teslimatı için benzersiz tanımlayıcı. | ||
| Açıklama Faturalandırma Olayı, belirli bir faturalandırılabilir hizmet için ücret yakalamadan hesap kapanışına kadar tüm faaliyetleri birbirine bağlayan birincil vaka tanımlayıcısı görevi görür. Tek bir talep veya hasta faturasının tüm yaşam döngüsünü temsil eder. Process Mining'de, her Faturalandırma Olayının yolculuğunu analiz etmek, gelir döngüsüne kapsamlı bir bakış açısı sağlar. Ortak süreç yollarını, sapmaları ve bireysel talepleri etkileyen darboğazları belirlemeye yardımcı olur. Bu ayrıntı düzeyi, süreç performansını anlamak ve talep gönderimindeki veya ödeme kayıtlarındaki gecikmeler gibi belirli iyileştirme alanlarını tespit etmek için çok önemlidir. Neden önemli Bu, tüm ilgili gelir döngüsü faaliyetlerini birbirine bağlayan temel Vaka Kimliğidir ve her faturalandırılabilir öğe için uçtan uca süreci izlemeyi mümkün kılar. Nereden alınır Bu, genellikle Waystar içindeki ana faturalandırma veya talep işlem tablosundan birincil anahtardır. Belirli tablo ve alan adı için Waystar belgelerine başvurun. Örnekler BE-2024-0012345BE-2024-0012346BE-2024-0012347 | |||
| Faaliyet Adı ActivityName | Gelir döngüsü sürecinde meydana gelen belirli iş olayının veya adımının adı, örneğin 'Talep Gönderildi' veya 'Ödeme Kaydedildi' gibi. | ||
| Açıklama Bu öznitelik, uçtan uca gelir döngüsü sürecini oluşturan bireysel faaliyetleri tanımlar. Her değer, bir faturalandırma olayında gerçekleştirilen farklı bir adımı, dönüm noktasını veya görevi temsil eder; örneğin, bir talep oluşturmak, bir ret almak veya bir ödeme kaydetmek gibi. Bu faaliyetlerin sırasını ve sıklığını analiz etmek, Process Mining'in temelidir. Süreç haritasının görselleştirilmesine, yeniden işleme döngülerinin belirlenmesine (örneğin, 'Talep Reddedildi' ardından 'Talep Düzeltildi') ve adımlar arasındaki geçiş sürelerinin ölçülmesine olanak tanır. Bu, süreç verimliliğini ve uyumluluğunu anlamak için kritik öneme sahiptir. Neden önemli Bu öznitelik, gelir döngüsü iş akışını görselleştirmek ve analiz etmek için temel olan süreç haritasındaki adımları tanımlar. Nereden alınır Waystar'ın talep ve faturalama modüllerindeki Örnekler Talep Ödeme Yapana SunulduHasar ReddedildiÖdeme KaydedildiHesap Kapatıldı | |||
| Olay Zaman Damgası EventTimestamp | Aktivitenin meydana geldiği kesin tarih ve saat. | ||
| Açıklama Olay Zaman Damgası, bir faaliyetin gerçekleştiği anı kaydeder. Bu zaman damgası, olayları kronolojik olarak sıralamak ve süreçteki farklı adımlar arasındaki süreleri hesaplamak için çok önemlidir. Süreç analizinde, zaman damgaları döngü süreleri, bekleme süreleri ve işlem süreleri gibi temel performans göstergelerini hesaplamak için kullanılır. Örneğin, 'Talep Gönderildi' zaman damgası ile 'Ödeme Kaydedildi' zaman damgası arasındaki fark, genel ödeme döngüsü süresini belirler. Doğru zaman damgaları, darboğaz analizi ve performans izleme için vazgeçilmezdir. Neden önemli Zaman damgaları, olayları sıralamak, döngü sürelerini hesaplamak ve süreç performansını analiz etmek için gereklidir, analizin zamansal omurgasını oluştururlar. Nereden alınır Bu, Waystar'daki hemen hemen her işlem veya durum değişikliği kaydıyla ilişkili standart bir alandır; genellikle 'Oluşturulma Tarihi', 'İşlem Tarihi' veya benzeri olarak adlandırılır. Örnekler 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z | |||
| Kaynak Sistem SourceSystem | Olay verilerinin kaynaklandığı sistem veya uygulama. | ||
| Açıklama Bu öznitelik, olay verilerini oluşturan kaynak sistemi tanımlar. Karmaşık bir BT ortamında, gelir döngüsü olayları Waystar içindeki farklı modüllerden veya hatta Elektronik Sağlık Kaydı (EHR) gibi entegre harici sistemlerden kaynaklanabilir. Kaynak sistemi anlamak, veri doğrulama, sorun giderme ve farklı sistem davranışlarından kaynaklanabilecek süreç varyasyonlarını anlamak için önemlidir. Süreç sorunlarını doğru uygulamaya veya arayüze atfetmeye yardımcı olur. Neden önemli Verinin kökenini belirler, bu da Nereden alınır Bu, veri çekimi sırasında eklenen statik bir değer ('Waystar') olabilir veya sistem içindeki belirli modüllerden veya tablolardan türetilebilir. Örnekler Waystar RCMWaystar Faturalandırma ModülüEHR Arayüzü | |||
| Son Veri Güncellemesi LastDataUpdate | Bu `event` için verilerin en son ne zaman yenilendiğini veya çıkarıldığını gösteren `timestamp`. | ||
| Açıklama Bu öznitelik, verilerin kaynak sistemden en son ne zaman çekildiğine dair bir zaman damgası sağlar. İş olayının gerçekleştiği zaman değil, kaydın analiz için çekildiği zamandır. Bu bilgi, veri yönetimi ve Process Mining analizindeki verilerin güncelliğini anlamak için kritik öneme sahiptir. Kullanıcıların güncel bilgilere bakıp bakmadıklarını bilmelerine yardımcı olur ve artımlı veri yüklerini yönetmek için esastır. Neden önemli
Nereden alınır Bu zaman damgası, genellikle veri alımı sırasında ETL (Extract, Transform, Load) süreci tarafından oluşturulur ve her satıra eklenir. Örnekler 2024-01-15T02:00:00Z2024-01-16T02:00:00Z | |||
| Faturalanan Tutar BilledAmount | Talepte sunulan hizmetler için tahsil edilen toplam para miktarı. | ||
| Açıklama Faturalanan Tutar, hastaya sunulan hizmetler için herhangi bir düzeltme, sözleşme indirimi veya ödeme uygulanmadan önceki brüt ücreti temsil eder. Ödeyene sunulan talebin başlangıç değeridir. Bu öznitelik, finansal analiz ve süreçten geçen parasal değeri anlamak için çok önemlidir. Talep değerine göre analizi bölümlere ayırmak, farklı hizmetler için ücret eğilimlerini belirlemek ve retler veya ödeme gecikmeleri gibi süreç verimsizliklerinin genel finansal etkisini hesaplamak için kullanılabilir. Çoğu finansal Dashboard için temel bir metriktir. Neden önemli Bir talebin toplam değerini temsil eder, süreç gecikmelerinin, retlerin ve düzeltmelerin finansal etki analizine olanak tanır. Nereden alınır Waystar'daki talep veya ücret giriş ekranında standart bir finansal alan. Örnekler 150.001250.75540.50 | |||
| Hasar Durumu ClaimStatus | Talebin yaşam döngüsündeki mevcut durumu, örneğin 'Gönderildi', 'Beklemede', 'Ödendi' veya 'Reddedildi' gibi. | ||
| Açıklama Talep Durumu, belirli bir Bu öznitelik, finansal raporlama ve operasyonel yönetim için kritik öneme sahiptir. Neden önemli Devam eden tüm taleplerin güncel bir görünümünü sunarak darboğazların analizini ve iş önceliklendirmesini sağlar. Nereden alınır Waystar'daki talep veya faturalama kaydında, talep döngü boyunca ilerledikçe güncellenen standart bir alan. Örnekler GönderildiÖdeme Yapan Tarafından OnaylandıReddedildiTamamı Ödendi | |||
| Hizmet Türü ServiceType | Sağlanan tıbbi hizmetin kategorisi veya türü, örneğin 'Radyoloji', 'Konsültasyon' veya 'Cerrahi Prosedür' gibi. | ||
| Açıklama Hizmet Türü, hastaya sunulan faturalandırılabilir hizmetin niteliğini sınıflandırır. Farklı hizmet türleri genellikle farklı faturalandırma kodlarına, geri ödeme oranlarına ve süreç karmaşıklıklarına sahiptir. Bu öznitelik, gelir döngüsünün klinik departman veya hizmet hattına göre ayrıntılı bir analizini sağlar. 'Hangi hizmet hatları en çok faturalandırma gecikmesi yaşıyor?' veya 'Cerrahi prosedürler için ret oranları danışmanlıklara göre daha mı yüksek?' gibi soruları yanıtlamaya yardımcı olur. Bu, departman performans analizi ve hedefe yönelik süreç iyileştirmesi için anahtardır. Neden önemli Klinik departman veya hizmet hattına göre süreç performansının analiz edilmesine olanak tanır, verimlilik ve karlılıktaki farklılıkları ortaya çıkarır. Nereden alınır Genellikle prosedür kodlarından (CPT/HCPCS) türetilir veya Waystar içinde hizmeti sağlayan departmana bağlanır. Örnekler RadyolojiKardiyoloji KonsültasyonuAcil Servis ZiyaretiAyaktan Ameliyat | |||
| Kalan Bakiye OutstandingBalance | Faturalandırma olayı için hala tahsil edilmesi gereken kalan para miktarı. | ||
| Açıklama Kalan Bakiye, belirli bir faturalandırma olayı için mevcut alacak miktarını temsil eder. Faturalanan tutardan bugüne kadar uygulanan ödemeler ve düzeltmeler çıkarılarak hesaplanır. Bu, nakit akışını ve alacakları yönetmek için kritik bir finansal metriktir. Kuruluşun toplam alacakları takip etmesini, yüksek bakiyeli hesapları belirlemesini ve tahsilat çabalarını önceliklendirmesini sağlayan 'Kalan Bakiyeler ve Yaşlandırma' Dashboard'u için birincil özniteliktir. Bu değeri zaman içinde izlemek, tahsilat sürecinin etkinliğini gösterir. Neden önemli Nakit akışını yönetmek, tahsilatları önceliklendirmek ve finansal sağlığı değerlendirmek için gerekli olan alacak hesaplarını doğrudan ölçer. Nereden alınır Bu, genellikle Waystar'ın raporlama modüllerinde hesaplanmış bir alandır (Faturalanan Tutar - Ödenen Tutar - Düzeltmeler). Doğrudan bir alan mevcut değilse veri çekimi sırasında hesaplanması gerekebilir. Örnekler 30.00270.25540.50 | |||
| Ödeyen Adı PayerName | Talepten sorumlu sigorta şirketinin veya üçüncü taraf ödeyenin adı. | ||
| Açıklama Bu öznitelik, bir sigorta şirketi, Medicare gibi bir devlet programı veya başka bir kuruluş gibi, talebi değerlendirmekten ve ödemekten sorumlu belirli ödeyeni tanımlar. Her ödeyenin farklı gönderim gereksinimleri, ödeme planları ve ret modelleri olabilir. Süreci Ödeyen Adı'na göre analiz etmek, hangi ödeyenlerin en uzun ödeme döngülerine, en yüksek ret oranlarına veya en karmaşık süreçlere sahip olduğunu belirlemek için hayati öneme sahiptir. Bu, kuruluşların stratejilerini uyarlamalarına, sorunlu ödeyenlerle takipleri önceliklendirmelerine ve daha iyi sözleşmeler müzakere etmelerine olanak tanır. Neden önemli Süreci ödeyene göre segmentlere ayırmak, ödeyene özel darboğazları, ret nedenlerini ve ödeme gecikmelerini belirlemek için kritik öneme sahiptir. Nereden alınır Waystar'daki hasta sigorta detaylarına bağlı olarak talep veya faturalama bilgilerinde bulunur. Örnekler AetnaBlue Cross Blue ShieldCignaMedicare B Kısmı | |||
| Ret Neden Kodu DenialReasonCode | Bir talebin ödeme yapan tarafından neden reddedildiğini gösteren standartlaştırılmış bir kod. | ||
| Açıklama Bir ödeyen bir talebi reddettiğinde, reddetmeyi açıklayan bir neden kodu sağlar. Bu kodlar, eksik bilgi, kapsam dışı hizmetler veya kodlama hataları gibi sorunları gösterebilir. Bu öznitelik o belirli kodu yakalar. Ret Neden Kodlarını analiz etmek, gelir döngüsünü iyileştirmek için temeldir. Kuruluşun, belirli bir departmandan sıkça gelen hatalar veya belirli bir ödeyenin gereksinimleriyle ilgili sorunlar gibi retlerin temel nedenlerini belirlemesine olanak tanır. Bu veriler, 'Talep Ret Oranı ve Nedenleri' Dashboard'unu doğrudan besler ve gelecekteki retleri önlemek ve ilk geçiş ödeme oranlarını iyileştirmek için stratejiler geliştirmede anahtardır. Neden önemli Bu öznitelik, talep retlerinin temel neden analizleri için hayati öneme sahiptir, gelir kaybını ve yeniden işleme oranını azaltmak için hedefe yönelik eylemleri mümkün kılar. Nereden alınır Reddetme olayı meydana geldiğinde talep kaydına doldurulur. Bu bilgi, ödeyen tarafından havale bildiriminde alınır. Örnekler CO-16: Talep/hizmet bilgisi eksikPR-96: Kapsam dışı ücret(ler)CO-22: Bu hizmet başka bir ödeme yapan tarafından karşılanabilir | |||
| Ayarlanan Tutar AdjustedAmount | Faturalandırma olayı için ayarlanan veya vazgeçilen toplam finansal tutar. | ||
| Açıklama Ayarlanan Tutar, bir faturalandırma olayının bakiyesine yapılan tüm finansal ayarlamaların toplamını temsil eder. Bu, ödeyen sözleşmeleri tarafından belirlenen sözleşme indirimlerini ve diğer vazgeçilen alacakları veya düzeltmeleri içerir. Bu, 'Hesap Ayarlama Oranı ve Etkisi' Dashboard'u için önemli bir metriktir. Bu tutarı farklı neden kodları veya ödeyenler arasında toplamak, gelir kaybının finansal etkisini ortaya koyar. Kayıpları ölçmeye yardımcı olur ve düzeltmelerin temel nedenlerini ele almak için bir iş gerekçesi sunar. Neden önemli Vazgeçilen alacaklar ve düzeltmeler nedeniyle kaybedilen gelir miktarını ölçer, faturalandırma sorunlarının ve sözleşme koşullarının finansal etkisini vurgular. Nereden alınır Waystar içindeki finansal düzeltme işlemlerinden elde edilir. Tek bir faturalandırma olayı için birden çok düzeltme girişini toplama gerektirebilir. Örnekler 250.2550.0015.80 | |||
| Düzeltme Neden Kodu AdjustmentReasonCode | Hesap bakiyesindeki finansal düzenlemenin nedenini açıklayan bir kod. | ||
| Açıklama Bir hesabın bakiyesi, sözleşme indirimi veya vazgeçilen alacak gibi ödeme dışındaki nedenlerle değiştirildiğinde, bunun nedenini belgelemek için bir Düzeltme Neden Kodu kullanılır. Bu öznitelik o kodu yakalar. Bu kodları analiz etmek, 'Hesap Ayarlama Oranı ve Etkisi' Dashboard'u için vazgeçilmezdir. Belirli ödeyenlerle sıkça yapılan sözleşme indirimleri veya faturalandırma hatalarından kaynaklanan vazgeçilen alacaklar gibi gelir kaybının temel nedenlerini belirlemeye yardımcı olur. Bu nedenleri anlamak, önlenebilir gelir kaybını en aza indirmeye yönelik ilk adımdır. Neden önemli Gelirin neden ayarlandığını veya silindiğini açıklar, gelir kaybı ve ödeme yapan sözleşme performansı hakkında kritik içgörüler sağlar. Nereden alınır Waystar'ın ödeme kaydı veya alacak hesapları modülündeki düzenleme işlemlerle ilişkilidir. Örnekler Sözleşmeye Dayalı YükümlülükKüçük Bakiye SilmeFaturalama Hatası Düzeltmesi | |||
| Hasta ID PatientId | Hizmeti alan hasta için benzersiz tanımlayıcı. | ||
| Açıklama Bu öznitelik, faturalandırma olayıyla ilişkili hasta için benzersiz tanımlayıcıdır. Finansal işlemi bakım alan kişiye geri bağlar. Faturalandırma Olayı bir vaka olsa da, Hasta Kimliği hasta merkezli analizlere olanak tanır. Tekrarlayan hastaları belirlemeye, birden çok ziyarette uçtan uca hasta finansal yolculuğunu anlamaya ve belirli hasta demografik bilgilerinin ödeme sorunları veya daha yüksek ret oranları ile ilişkili olup olmadığını analiz etmeye yardımcı olabilir. Tek bir kişi için tüm faturalandırma faaliyetlerini bir araya getirme yolu sağlar. Neden önemli Hasta merkezli analize olanak tanır, bir birey için birden çok Nereden alınır Waystar'daki talep veya hasta kayıt kaydında veya bir EHR'den bağlantılı standart bir alan. Örnekler MRN-887654MRN-902101MRN-123456 | |||
| Hasta Sınıfı PatientClass | Hasta'nın karşılaşma durumunu, örneğin 'Yatan Hasta' veya 'Ayakta Hasta' olarak gösterir. | ||
| Açıklama Hasta Sınıfı, hasta karşılaşmasının türünü kategorize eder ve bu genellikle faturalandırma kurallarını ve geri ödeme oranlarını belirler. Yaygın sınıflar arasında Yatan Hasta, Ayakta Hasta ve Acil durum bulunur. Hasta Sınıfına göre gelir döngüsünü analiz etmek, önemli süreç farklılıklarını ortaya çıkarabilir. Örneğin, yatan hasta talepleri genellikle ayakta hasta taleplerinden daha karmaşık ve daha uzun ödeme döngülerine sahiptir. Bu segmentasyon, gerçekçi performans hedefleri belirlemek ve süreç iyileştirme girişimlerini her sınıfın özel ihtiyaçlarına göre uyarlamak için önemlidir. Neden önemli Süreci karşılaşma karmaşıklığına (örneğin, yatan hasta ve ayakta hasta) göre bölümlendirmeye yardımcı olur; bu da genellikle farklı faturalama kuralları ve döngü süreleriyle ilişkilidir. Nereden alınır Waystar veya kaynak EHR içindeki hasta kaydı veya karşılaşma verilerinde standart bir alan. Örnekler Yatan HastaAyakta TedaviAcil | |||
| Hizmetten Faturaya Süre ServiceToInvoiceCycleTime | Bir hizmetin tamamlandığı andan, ücretlerin yakalandığı ve bir talebin oluşturulduğu ana kadar geçen süre. | ||
| Açıklama Bu metrik, 'ücret gecikmesi' olarak da bilinir, ön uç faturalandırma sürecinin verimliliğini ölçer. 'Hizmet Sağlandı/Tamamlandı' olayı ile 'Ücretler Yakalandı' veya 'Talep Oluşturuldu' olayı arasındaki zaman farkı olarak hesaplanır. Bu öznitelik, 'Hizmetten Faturaya Döngü Süresi' Dashboard'unu doğrudan destekler. Sürecin bu kısmındaki gecikmeler, yani ücret gecikmesi, ödeme döngüsünün başlangıcını doğrudan erteler, nakit akışını geciktirir. Bunu izlemek, tüm hizmetlerin hızlı ve doğru bir şekilde faturalandırılmasını sağlayarak kaybedilen geliri önlemeye ve tüm gelir döngüsünü hızlandırmaya yardımcı olur. Neden önemli Ön uç faturalama verimliliğini ölçer. Bu 'ücret gecikmesini' azaltmak, tüm gelir döngüsünü hızlandırmak ve kaybedilen ücretleri önlemek için çok önemlidir. Nereden alınır
Örnekler 2 gün 8 saat1 gün 0 saat5 gün 1 saat | |||
| İlk Geçiş Ödemesi mi IsFirstPassPayment | Talebin ilk gönderimde herhangi bir ret veya düzeltme olmaksızın doğru şekilde ödenip ödenmediğini belirten bir işaret. | ||
| Açıklama Bu hesaplanmış boolean öznitelik, bir talebin ret, reddetme veya daha fazla bilgi talebi gibi herhangi bir olumsuz olay olmadan ödenip ödenmediğini gösterir. 'Doğru' değeri, o talep için temiz, verimli bir süreci ifade eder. Bu öznitelik, genel gelir döngüsü verimliliğinin kritik bir ölçütü olan 'İlk Geçiş Ödeme Oranı' KPI'sını doğrudan destekler. İlk geçişte ödenmeyen taleplerin özelliklerini (örn. ödeyene, hizmet türüne göre) analiz etmek, yeniden işleme ve ödeme gecikmelerinin birincil nedenlerini belirlemeye yardımcı olur. Bu oranı iyileştirmek, daha hızlı nakit akışına ve daha düşük operasyonel maliyetlere yol açar. Neden önemli Faturalama ve talep işleme kalitesini doğrudan ölçer. Yüksek bir ilk geçiş ödeme oranı, minimal yeniden işleme ile verimli bir sürece işaret eder. Nereden alınır Bu, veri dönüşümü sırasında hesaplanan türetilmiş bir özniteliktir. Mantık, 'Ödeme Kaydedildi' olayının 'Talep Reddedildi' veya 'Hesap Ayarlandı' gibi olaylardan önce gerçekleşip gerçekleşmediğini kontrol eder. Örnekler truefalse | |||
| Ödeme Döngü Süresi PaymentCycleTime | Bir talebin gönderildiği andan son ödemenin kaydedildiği ana kadar geçen toplam süre. | ||
| Açıklama Bu hesaplanmış metrik, temel ödeme tahsilat sürecinin süresini ölçer. Genellikle bir faturalandırma olayı için 'Ödeyene Gönderilen Talep' olayı ile nihai 'Ödeme Kaydedildi' olayı arasındaki zaman farkı olarak hesaplanır. Bu öznitelik, 'Genel Ödeme Döngüsü Süresi Analizi' Dashboard'u için birincil ölçüttür ve nakit akışı için temel bir performans göstergesidir. Bu süreyi farklı ödeyenler, hizmet türleri veya hasta sınıfları arasında analiz etmek, ödeme almada en büyük gecikme kaynaklarını belirlemeye yardımcı olur. Ortalama ödeme döngüsü süresini azaltmak, neredeyse tüm gelir döngüsü yönetimi girişimleri için birincil hedeftir. Neden önemli Nakit tahsilat hızını ölçen temel bir KPI. Analiz edilmesi, ödeme sürecindeki en önemli gecikmeleri belirlemeye ve gidermeye yardımcı olur. Nereden alınır
Örnekler 25 gün 4 saat90 gün 11 saat14 gün 2 saat | |||
| Ödenen Miktar PaidAmount | Ödeyenlerden veya hastadan talep için alınan ve kaydedilen toplam para miktarı. | ||
| Açıklama Bu öznitelik, bir faturalandırma olayı için başarıyla tahsil edilen toplam para miktarını kaydeder. Bu, birincil ve ikincil sigorta ödeyicilerinden gelen ödemeleri ve hastadan gelen ödemeleri içerir. Ödenen Tutar, gelir döngüsü için önemli bir sonuç metriğidir. Faturalanan ücretler üzerindeki nihai getiriyi hesaplamak ve tüm sürecin etkinliğini ölçmek için kullanılır. Faturalanan Tutar ile Ödenen Tutar'ı karşılaştırmak, finansal performansı ortaya koyar ve gelir kaybı alanlarını vurgular. Tahsilat etkinliği ve genel finansal sağlıkla ilgili Dashboard'lar için vazgeçilmezdir. Neden önemli Gelir döngüsü sürecinin genel başarısını değerlendirmek için birincil sonuç metriği olan gerçek nakit tahsilatını ölçer. Nereden alınır Waystar'daki taleple bağlantılı ödeme kaydı işlemlerinden türetilmiştir. Birden fazla ödeme kaydının toplanmasını gerektirebilir. Örnekler 120.00980.500.00 | |||
| Ödeyen Tipi PayerType | Ödeyenin kategorisi, örneğin 'Ticari', 'Medicare' veya 'Kendi Ödemeli' gibi. | ||
| Açıklama Ödeyen Türü, bireysel ödeme yapanları yapılarına göre daha geniş kategorilere ayırır. Bu, belirli Ödeyen Adı'ndan daha üst düzey bir görünüm sağlar. Bu öznitelik stratejik analiz ve raporlama için faydalıdır. Liderliğin, devlet ödeme yapanları ile ticari sigortacıların genel performansını karşılaştırma gibi büyük ödeyen kategorileri genelindeki performans eğilimlerini anlamasına olanak tanır. Bu, ödeyen sözleşmeleri ve kaynak tahsisi hakkında stratejik kararları bilgilendirebilir. Neden önemli Ödeme yapanları Ticari veya Kamu gibi kategorilere ayırarak üst düzey analize olanak tanır; bu kategoriler genellikle farklı ödeme davranışlarına ve kurallarına sahiptir. Nereden alınır Genellikle Ödeyen Adı'nın önceden tanımlanmış bir kategori listesine eşleştirilmesiyle türetilir. Bu mantık Waystar'da mevcut olabilir veya veri dönüşümü sırasında oluşturulması gerekebilir. Örnekler TicariMedicareMedicaidKendi Ödemeli | |||
| Son Ödeme Tarihi PaymentDueDate | Fatura veya talep için ödemenin beklendiği tarih. | ||
| Açıklama Ödeme Vadesi, sağlayıcı tarafından belirlenen veya ödeyen sözleşmeleri tarafından ödemenin alınması gereken tarihi gösterir. Ödeme zamanlamasını ölçmek için bir referans noktası görevi görür. Bu öznitelik, 'Kalan Bakiyeler ve Yaşlandırma' Dashboard'u için vazgeçilmezdir. Alacakların yaşını hesaplamak ve onları '0-30 gün', '31-60 gün' vb. gibi gruplara ayırmak için kullanılır. Bu yaşlandırma analizi, alacakları yönetmek ve gecikmiş hesaplardaki tahsilat çabalarını önceliklendirmek için standart bir finansal uygulamadır. Neden önemli Tahsilatları yönetmek ve nakit akışı zamanlamasını anlamak için kritik olan alacak yaşlandırma hesaplaması için temel sağlar. Nereden alınır Fatura veya talep kaydında bulunabilir. Fatura tarihine ve ödeme koşullarına göre hesaplanabilir. Örnekler 2023-11-252023-12-152024-01-30 | |||
| Sorumlu Kullanıcı ResponsibleUser | Fatura kesen, kodlayıcı veya tahsilat uzmanı gibi faaliyeti gerçekleştiren kullanıcı veya aracı. | ||
| Açıklama Bu öznitelik, süreçte belirli bir etkinliği gerçekleştiren belirli çalışanı veya sistem kullanıcısını tanımlar. Örneğin, hangi fatura kesicinin bir talep gönderdiğini veya hangi tahsilatçının bir takip araması başlattığını gösterebilir. Süreci kullanıcıya göre analiz etmek, iş yükü dağılımını, bireysel performansı ve eğitim ihtiyaçlarını anlamaya yardımcı olur. Belirli kullanıcıların daha yüksek hata oranlarına sahip olup olmadığını veya retleri çözmede daha verimli olup olmadığını vurgulayabilir. Bu, gelir döngüsü departmanındaki ekip yönetimi ve kalite kontrolü için değerlidir. Neden önemli Süreç adımları için hesap verebilirliği atar, bireysel veya ekip düzeyinde performans analizini ve eğitim fırsatlarını belirlemeyi sağlar. Nereden alınır Waystar'daki Örnekler jsmithadavisbilling_bot_01 | |||
Gelir Döngüsü Yönetimi Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hasar Karara Bağlandı | Ödeyen talebi işledi ve bir ödeme kararı verdi. Bu olay, ödeyenden bir Elektronik Havale Bildirimi (ERA) veya 835 dosyası alındığında yakalanır. | ||
| Neden önemli Bu, süreçteki birincil karar noktasıdır. Talebin ödenip ödenmeyeceğini veya reddedilip reddedilmeyeceğini belirler, bu da gelir akışını ve ret yönetimi iş akışlarını doğrudan etkiler. Nereden alınır Waystar'daki taleple ilişkili ERA (835 dosyası) alım tarihinden çıkarılmıştır. ERA dosyası, ödeme yapanın ayrıntılı kararını içerir. Yakala Ödeme yapandan alınan ERA/835 dosyasının işleme tarihinden çıkarılmıştır. Event tipi inferred | |||
| Hasar Reddedildi | Ödeyen talebi reddetti ve Elektronik Havale Bildirimi'nde (ERA) detaylandırıldığı gibi ödeme yapmayacak. Bu olay, ret yönetimi veya yeniden işleme döngüsünü tetikler. | ||
| Neden önemli Doğrudan 'Talep Ret Oranı' KPI'sını destekler. Retlerin sıklığını ve nedenlerini belirlemek, süreç iyileştirme ve gelir kurtarma için kritiktir. Nereden alınır Bu, alınan ERA (835 dosyası) içindeki Talep Düzeltme Neden Kodları (CARC'ler) olarak bilinen belirli ret kodlarından çıkarılır. Yakala ERA dosyasındaki reddetmeyi gösteren talep düzeltme neden kodlarından (CARC'lar) türetilmiştir. Event tipi inferred | |||
| Hesap Kapatıldı | Faturalandırma olayının yaşam döngüsü tamamlanmıştır, hesap bakiyesi ödemeler ve düzeltmeler yoluyla sıfıra ulaşmıştır. Bu, bu vaka için gelir döngüsünün başarılı bir şekilde sona erdiğini gösterir. | ||
| Neden önemli Bu, sürecin birincil bitiş noktasıdır. Kapanış süresini ve başarılı bir şekilde kapanan hesapların yüzdesini ölçmek, temel genel performans göstergeleridir. Nereden alınır Bu, hasta muhasebe sisteminde faturalandırma olayı için kalan bakiye alanı sıfır olduğunda genellikle çıkarılan hesaplanmış bir olaydır. Yakala Ödemelerin ve düzeltmelerin toplamı, toplam ücret tutarına eşit olduğunda hesaplanır. Event tipi calculated | |||
| Ödeme Kaydedildi | Alınan bir ödeme, belirli hasta hesabına ve talebine uygulanır veya mutabakatı yapılır. Bu faaliyet, bakiyeyi alacak hesaplardan nakde taşır. | ||
| Neden önemli Bu, ödeyen döngüsündeki kritik bir son adımdır. Ödeme kaydı verimini ve gecikme süresi KPI'larını destekler, hesapların zamanında ve doğru bir şekilde güncellenmesini sağlar. Nereden alınır Bu, bir kullanıcının ERA'dan ödemeyi kaydettiğinde Waystar'da günlüğe kaydedilen açık bir eylemdir. Birçok sistemde bu olayı da günlüğe kaydeden otomatik kayıt özellikleri bulunur. Yakala Bir ERA'dan gelen ödeme, manuel veya otomatik kayıt yoluyla bir talebe uygulandığında kaydedilen Event tipi explicit | |||
| Talep Ödeme Yapana Sunuldu | Faturalandırma talebinin sigorta ödeyene elektronik olarak ibraz edilmesi. Bu, sağlayıcının sisteminden takas odası aracılığıyla ödeyenin sistemine kritik bir devirdir. | ||
| Neden önemli Ödeme yapanın yanıt sürelerini başlatan önemli bir kilometre taşıdır. Ödeme döngüsü KPI'larını ölçmek ve gönderim birikimlerini belirlemek için esastır. Nereden alınır Waystar'ın takas odası işlevselliği, talep dosyası iletiminin tarih ve saatini açıkça kaydeder. Gönderim günlüklerini veya talep durumu geçmişini arayın. Yakala Başarılı iletim üzerine talep gönderim geçmişine veya işlem günlüğüne kaydedildi. Event tipi explicit | |||
| Ücretler Yakalandı | Faturalanabilir hizmetlerin gelir döngüsü sistemine girişini işaretler. Bu `event`, genellikle bir kullanıcı bir ücret girişini kesinleştirdiğinde veya bir klinik sistemden `data` alındığında açıkça kaydedilir. | ||
| Neden önemli Bu, faturalandırma sürecinin başlangıç noktasıdır. Hizmet tamamlanmasından ücret yakalamaya kadar geçen süreyi analiz etmek, gelir kaybını ve ön uç gecikmelerini belirlemek için çok önemlidir. Nereden alınır Bu olay, Waystar içinde bir ücret girişi veya işlem tablosunda kaydedilir ve genellikle ücret kaydedildiğinde veya kesinleştirildiğinde bir oluşturulma zaman damgası içerir. Yakala Bir ücret girişi kaydedildiğinde veya kesinleştirildiğinde kaydedilen Event tipi explicit | |||
| Hasar Oluşturuldu | Yakalanan ücretlerden resmi bir faturalandırma talebinin oluşturulmasını temsil eder. Bu, sistemin ödeyene göndermeden önce bilgileri derlediği dahili bir adımdır. | ||
| Neden önemli Talep oluşturmanın dahili verimliliğini takip eder. Bu aşamadaki gecikmeler, talep sağlayıcının sisteminden ayrılmadan önce bile tüm ödeme döngüsünü erteleyebilir. Nereden alınır Bu açık bir olay olabilir, ancak genellikle Waystar'ın talep yönetim modülündeki bir talep kaydıyla ilişkili ilk zaman damgasından çıkarılır. Yakala Birincil talep tablosundaki talep kaydının oluşturulma tarihinden çıkarılmıştır. Event tipi inferred | |||
| Hasta Bakiye Ekstresi Gönderildi | Sigorta karara bağlandıktan sonra, kalan bakiye için hastaya bir hesap özeti oluşturulur ve gönderilir. Bu, tahsilat odağını ödeme yapandan hastaya kaydırır. | ||
| Neden önemli Bu olay, hasta ödeme döngüsünü başlatır. Ekstrelerin etkinliğini ve zamanlamasını analiz etmek, hasta alacaklarını yönetmek ve hasta deneyimini iyileştirmek için anahtardır. Nereden alınır Bu, hasta faturalandırma modülü tarafından bir ekstre grubu oluşturulduğunda veya elektronik olarak veya bir basım satıcısına gönderildiğinde günlüğe kaydedilen açık bir olaydır. Yakala Bir hesap özeti oluşturulduğunda hasta yazışma geçmişine kaydedilen Event tipi explicit | |||
| Hesap Düzenlendi | Hesap bakiyesinde manuel veya sözleşmeye dayalı bir düzeltme yapılır. Bu, silinmeleri, sözleşmeye dayalı indirimleri, hasta indirimlerini veya diğer düzeltmeleri içerebilir. | ||
| Neden önemli Gelir kaybını anlamak için esastır. Düzeltmeleri analiz etmek, ücret çizelgeleri, sözleşme yönetimi veya tahsil edilemeyen borçlarla ilgili sorunları belirlemeye yardımcı olur. Nereden alınır Her finansal düzeltme, denetim amaçları için bir işlem olarak kaydedilmelidir. Bu, hesap işlem tablosunda açık bir Yakala Hesap defterinde belirli bir işlem türü olarak kaydedildi. Event tipi explicit | |||
| Ödeyen Onayı Alındı | Ödeyenin sistemi, gönderilen talep dosyasının alındığını onaylar. Bu genellikle, talebin işlenmek üzere kabul edildiğini gösteren 277CA veya 999 raporu gibi otomatik bir yanıttır. | ||
| Neden önemli Başarılı iletimi onaylar ve karara bağlama başlamadan önce biçimlendirme veya Nereden alınır Gelen bir ödeyen teyit dosyası işlendikten sonra Waystar'ın takas odası modülündeki talep durumu veya yanıt dosyası tablolarına kaydedilir. Yakala Ödeme yapandan elektronik bir onay dosyası işlendiğinde kaydedilen Event tipi explicit | |||
| Ret İtiraz Edildi | Bir kullanıcı, genellikle talebi düzeltmelerle yeniden göndererek veya resmi bir itiraz sunarak bir talep reddine itiraz etmek için harekete geçti. Bu faaliyet, yeniden işleme sürecinde önemli bir adımdır. | ||
| Neden önemli Ret yönetimi ekibinin verimliliğini ölçer. Retten itiraza kadar geçen süreyi ve itirazların başarı oranını takip etmek, kurtarma çabalarını optimize etmek için önemlidir. Nereden alınır Bu, ret yönetimi modülünde açık bir kullanıcı eylemi veya not olarak kaydedilebilir. Ayrıca reddedilen talepteki bir durum değişikliğinden de çıkarılabilir. Yakala Bir kullanıcı itiraz eylemini belgelediğinde veya talep durumunu 'İtiraz Edildi' olarak güncellediğinde kaydedilen Event tipi explicit | |||
| Tahsilat Faaliyeti Başlatıldı | Hasta hesabı gecikmiş hale gelmiştir ve aktif tahsilat çabaları başlamıştır. Bu, otomatik hatırlatmaları veya üçüncü taraf tahsilat ajansına devri içerebilir. | ||
| Neden önemli 'Tahsilat Faaliyeti Etkinliği' Dashboard'unu destekler. Yaşlanan alacaklardaki tahsilat çabalarının maliyetini ve başarı oranını analiz etmeye yardımcı olur. Nereden alınır Bu, genellikle Waystar'daki hesap durumunun 'Tahsilatlar' veya 'Batık Alacak' durumuna geçmesinden çıkarılır, bu da farklı bir iş akışını tetikler. Yakala Hesap durumunun 'Tahsilatlar' veya 'Kötü Borç' olarak değişmesinden çıkarılmıştır. Event tipi inferred | |||
| Talep Düzeltildi ve Yeniden Gönderildi | Bir ret veya reddetme sonrasında, talep düzeltilip ödeme yapana geri gönderildi. Bu, belirli bir talep için karara bağlama döngüsünün yeniden başladığını gösterir. | ||
| Neden önemli Bu kritik bir yeniden işleme döngüsüdür. Yeniden gönderme sıklığını ve nedenlerini analiz etmek, kodlama veya demografik hatalar gibi ilk hataların temel nedenlerini belirlemeye yardımcı olur. Nereden alınır Daha önce reddedilmiş bir talep için yeni bir 'Claim Submitted To Payer' Yakala Daha önce reddedilmiş bir talep tanımlayıcısına bağlı yeni bir gönderim Event tipi inferred | |||
Veri Çekim Kılavuzları
Bu süreç için veri çıkarma yöntemleri şu anda doğrulanmaktadır. Lütfen daha sonra tekrar kontrol edin veya bize ulaşın yardım için.