Gelir Döngüsü Yönetimi Veri Templateiniz

Bu nitelik, belirli bir faturalandırma olayı için gelir döngüsü yönetimi süreci içindeki tek bir adımı veya dönüm noktasını tanımlar. Etkinlikler, 'Ücretler Yakalandı', 'Talep Gönderildi' veya 'Ödeme Kaydedildi' gibi yapılan işi temsil eder.\n\nEtkinlik dizisini analiz etmek, Process Mining'in çekirdeğidir. Bu, gerçek süreç akışının keşfedilmesine, etkinliklerin başlaması için çok uzun sürdüğü bottlenecklerin (darboğazların) belirlenmesine ve 'Talep Reddedildi' ardından 'Reddi Yeniden İşleme Başlatıldı' gibi etkinliklerin gereksiz yere tekrarlandığı yeniden işleme döngülerinin tespit edilmesine olanak tanır.

Süreçteki adımları tanımlar, süreç haritasının görselleştirilmesine, geçiş sürelerinin hesaplanmasına ve süreç sapmalarının ve yeniden işleme miktarının belirlenmesine olanak tanır.

Bu bilgi, genellikle R1 RCM'nin çeşitli modüllerindeki event loglarından (olay günlüklerinden), durum değişikliği kayıtlarından veya işlem kodlarından türetilir. Teknik kodlardan iş dostu adlara eşleme gerektirebilir.

Faturalandırma Olayı Kimliği, bir ücrete yol açan hizmet veya ürün teslimatının ayrı bir örneğini temsil eder. İlk hizmet sunumu ve ücret yakalamasından talep gönderimine, ödeme kaydına ve nihai hesap kapanışına kadar tüm ilgili etkinlikleri birbirine bağlayan merkezi bir iplik görevi görür.\n\nProcess mining'de, her Faturalandırma Olayının yaşam döngüsünü analiz etmek, uçtan uca gelir döngüsünün kapsamlı bir görünümünü sağlar. Tek bir ücretin tüm yolculuğunu izlemek, ortak yolları belirlemek, ana dönüm noktaları arasındaki döngü sürelerini ölçmek ve gecikmelere veya gelir kaybına yol açan varyasyonları anlamak için kullanılır.

Bu tanımlayıcı, tüm ilgili etkinlikleri tek bir casede (durumda) gruplandırmak için temeldir ve her faturalandırılabilir event (olay) için gelir döngüsünün eksiksiz ve doğru bir süreç analizine olanak tanır.

Bu, hasta görüşmeleri, ücretler, talepler ve ödemelerle ilgili çeşitli tabloları birbirine bağlayan birincil anahtardır. Belirli alan için R1 RCM dokümantasyonuna bakın, genellikle bir görüşme veya talep tanımlayıcısıyla ilgilidir.

Event Time, bir aktivitenin sisteme kaydedildiği kesin tarih ve saati sağlar. Bu zamansal bilgi, süreci zaman tabanlı bir analizden anlamak için temeldir.

Process mining'de bu zaman damgası, olayları kronolojik olarak sıralamak ve aktiviteler arasındaki süreleri hesaplamak için kullanılır, bu da performans analizi için kritik öneme sahiptir. Döngü süresi, işleme süresi ve bekleme süresi gibi temel metriklerin hesaplanmasını sağlar, bunlar darboğazları belirlemek ve verimliliği ölçmek için gereklidir.

Bu timestamp (zaman damgası), döngü sürelerini hesaplama, bottleneckleri (darboğazları) belirleme ve süreç performansını SLA'lara karşı izleme dahil olmak üzere tüm zamanla ilgili analizlerin temelidir.

Genellikle R1 RCM'deki her işlem veya durum değişikliği kaydıyla ilişkili bir 'Oluşturma Tarihi', 'Timestamp' (Zaman Damgası) veya 'Son Güncelleme Tarihi' alanı olarak bulunur.

Bu nitelik, belirli bir event (olay) için veri oluşturan kaynak uygulamayı veya modülü tanımlar. Sağlık hizmetleri gibi karmaşık bir ortamda, veri bir EMR'den, faturalandırma modülünden, talep takas merkezinden veya tahsilat platformundan gelebilir.\n\nKaynak sistemi anlamak, veri doğrulaması ve belirli sistemlere özgü olabilecek süreç varyasyonlarını analiz etmek için çok önemlidir. Veri tutarsızlıklarını gidermeye ve sürecin teknolojik manzarasını anlamaya yardımcı olur.

Verinin kaynağını belirler, bu da data governance, doğrulama ve uçtan uca süreçte farklı sistemlerin nasıl etkileşim kurduğunu anlamak için kritik öneme sahiptir.

Bu, genellikle veri çıkarma işlemi sırasında eklenen statik bir değerdir ve verilerin (örn: 'R1 RCM') kaynaklandığı sistemi tanımlar.

Bu nitelik, Process Mining analizine yönelik verilerin en son ne zaman güncellendiğini gösterir. Analiz edilen verilerin güncelliği hakkında bağlam sağlar.\n\nBu bilgi, raporlama ve dashboardlar için önemlidir, çünkü kullanıcıya süreç içgörülerinin ne kadar güncel olduğunu söyler. Verilerin zamanında olmasıyla ilgili beklentileri yönetmeye ve kararların anlaşılan bir zaman çerçevesine göre verilmesini sağlamaya yardımcı olur.

Veri güncelliği hakkında kritik bağlam sağlar, analistlerin ve paydaşların süreç içgörülerinin ne kadar güncel olduğunun farkında olmasını temin eder.

Bu timestamp (zaman damgası), veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında oluşturulur ve genellikle tüm veri kümesine uygulanır.

Bu nitelik, süreçteki belirli bir görevi yürütmekten sorumlu kişiyi tanımlar. Bu, talebi oluşturan faturalandırıcı, ret işlemini yeniden yapan analist veya ödemeyi kaydeden uzman olabilir.\n\nKullanıcıya göre analiz yapmak, iş yükü dağılımını, bireysel performansı ve eğitim ihtiyaçlarını anlamaya yardımcı olur. Hangi kullanıcıların en verimli olduğunu veya hangilerinin daha yüksek hata oranlarıyla ilişkili olabileceğini vurgulayarak, hedeflenen yönetim ve süreç iyileştirme çabalarına olanak tanır.

Ekip ve bireysel performansın, iş yükü dağıtımının analiz edilmesini sağlar ve eğitim fırsatlarını veya kullanıcıya özel süreç sapmalarını belirlemeye yardımcı olur.

Genellikle R1 RCM içindeki işlem günlüklerinde 'UserID', 'Processor' veya 'UpdatedBy' alanı olarak bulunur.

Bu nitelik, 'Ücret Girişi', 'Talep Gönderimi' veya 'Red Yönetimi' gibi belirli bir süreç adımını yürüten organizasyonel birimi belirtir. Farklı ekipler arasında işin nasıl aktarıldığını anlamaya yardımcı olur.\n\nBu, departman verimliliğini analiz etmek ve çapraz fonksiyonel bottleneckleri (darboğazları) belirlemek için çok önemlidir. Süreç haritasını departmana göre filtreleyerek, kuruluşlar işin sorunsuz aktarıldığı yerleri ve gecikmelerin meydana geldiği yerleri görebilir, bu da kaynak tahsisini ve organizasyonel süreç optimizasyonunu destekler.

Kuruluş birimine göre süreç performansının analiz edilmesine olanak tanıyarak, ekibe özel darboğazları, kaynak kısıtlamalarını veya en iyi uygulamaları belirlemeye yardımcı olur.

Bu, R1 RCM'deki kullanıcının profilinden türetilebilir veya işlem verilerinde 'Departman Kodu' olarak saklanabilir.

Bu nitelik, bir faturalandırma eventinin (olayının) bilinen son durumunu gösterir; örneğin 'Gönderildi', 'Ödendi', 'Reddedildi' veya 'Tahsilatta'. Bir faturanın belirli bir zamanda süreçte nerede olduğuna dair bir anlık görüntü sağlar.\n\nFatura durumu, yaşlandırma raporları oluşturmak ve alacak hesaplarının sağlığını izlemek için hayati öneme sahiptir. Process Mining'de, belirli bir durumda takılı kalmış caseleri (durumları) filtrelemek veya farklı süreç varyantlarının sonuçlarını analiz etmek için kullanılabilir, örneğin 'Ödendi' ile 'Reddedildi' taleplerinin yollarını karşılaştırmak gibi.

Her bir casein (durumun) mevcut durumunu sunar; bu, yaşlandırma raporları oluşturmak ve farklı süreç yollarının nihai sonuçlarını analiz etmek için hayati öneme sahiptir.

Bu, tipik olarak R1 RCM'deki ana talep veya hesap kaydındaki bir durum alanıdır.

Bu nitelik, belirli bir faturalandırma eventinde (olayında) sunulan hizmetler için faturalandırılan toplam tutarı temsil eder. Talepten beklenen geliri yansıtır.\n\nFatura tutarını analiz etmek, finansal Process Mining için kritik öneme sahiptir. Yüksek değerli talepleri önceliklendirmeye, süreç gecikmelerinin veya retlerinin finansal etkisini anlamaya ve süreci değere göre bölümlere ayırmaya olanak tanır. Örneğin, bir analiz belirli bir miktarın üzerindeki taleplerin farklı, daha manuel bir süreç yolunu izlediğini ortaya çıkarabilir.

Sürece finansal bağlam sağlar, süreç varyasyonlarının geliri nasıl etkilediğinin analiz edilmesini mümkün kılar ve iyileştirme için yüksek değerli caselerin (durumların) önceliklendirilmesine yardımcı olur.

R1 RCM'deki ana talep veya fatura başlık tablosunda bulunur, genellikle 'TotalBilledAmount' veya benzeri bir adla anılır.

Bu nitelik, talep için birincil ödeyiciyi tanımlar. Bu, Aetna gibi ticari bir sigortacı, Medicare gibi bir devlet ödeyicisi veya kendi ödeme yapan kısımlar için hastanın kendisi olabilir.\n\nÖdeyiciye göre süreci analiz etmek, gelir döngüsü yönetimi için temeldir. Belirli ödeyicilerin daha yüksek ret oranlarına, daha uzun ödeme döngülerine veya daha karmaşık gönderim gereksinimlerine sahip olduğunu ortaya çıkarabilir. Bu içgörüler, kuruluşun ödeyiciye özgü davranışları etkili bir şekilde yönetmek için süreçlerini ve kaynaklarını uyarlamasına olanak tanır.

Sürecin ödeyiciye göre segmentlere ayrılmasını sağlayarak, ödeyiciye özgü gecikmeleri, reddetme modellerini veya ödeme davranışlarını belirlemek için önemlidir, bu da geliri optimize etmek için hayati öneme sahiptir.

R1 RCM'deki taleple bağlantılı hastanın sigorta veya demografik bilgilerinde bulunur.

Bir ödeyici bir talebi reddettiğinde, kararı açıklamak için bir CARC (Talep Düzenleme Nedeni Kodu) gibi bir neden kodu sağlar. Bu kodlar standartlaştırılmıştır ve 'Kapsanmayan Hizmet' veya 'Çift Talep' gibi sorunları gösterir.\n\nBu nitelik, ret yönetimi için son derece önemlidir. Farklı ret nedeni kodlarının sıklığını analiz ederek, kuruluşlar retlerin kök nedenlerini, hasta uygunluğu, kodlama hataları veya tıbbi gereklilik eksikliği ile ilgili olup olmadığını belirleyebilir ve ele alabilir. Bu, yeniden işlemeyi azaltma ve nakit akışını hızlandırma çabalarını doğrudan destekler.

Talep retlerinin özel nedenini sunar, gelecekteki retleri azaltmak, yeniden işleme süreçlerini düşürmek ve ilk geçiş ödeme oranlarını iyileştirmek için kök neden analizine olanak tanır.

Bu bilgi, ödeyiciden gelen elektronik havale bildirimi (ERA veya 835 dosyası) olarak alınır ve R1 RCM'nin talep yönetimi modülünde saklanır.

Bu nitelik, bir hesaba neden finansal düzeltme yapıldığına dair bağlam sağlar. Nedenler genellikle düzeltme türünü kategorize eden standartlaştırılmış kodlar veya açıklamalardır.\n\nDüzenleme nedenlerini analiz etmek, gelir kaybının kök nedenlerini teşhis etmeye yardımcı olur. Örneğin, 'Küçük Bakiye Silme'nin yüksek sıklığı, küçük tutarlar için verimsiz bir tahsilat sürecine işaret edebilirken, sık 'Sözleşmeye Dayalı İndirimler' ödeyici müzakerelerinin beklenen bir parçasıdır. Bu analiz, Faturalandırma Düzenlemeleri ve Uyumluluk Denetimi dashboardını destekler.

Gelir ayarlamalarının ardındaki 'nedeni' açıklar, sözleşmesel sorunlar, faturalama hataları veya tahsilat başarısızlıkları gibi gelir kaybının temel nedenlerini belirlemeye yardımcı olur.

Bu, tipik olarak R1 RCM'deki AdjustmentAmount ile aynı işlem kaydındaki bir kod veya metin alanıdır.

Bu nitelik, ilk faturalandırmadan sonra bir hastanın hesabında yapılan finansal düzenlemelerin değerini yakalar. Düzenlemeler pozitif veya negatif olabilir ve sözleşmeye dayalı indirimleri, silmeleri veya düzeltmeleri içerebilir.\n\nDüzenleme tutarlarını izlemek, gelir bütünlüğünü anlamak için kritik öneme sahiptir. Yüksek seviyede negatif düzenlemeler, yanlış ücret yakalama veya tahsil edilemeyen borç gibi sorunlardan kaynaklanan gelir kaybını gösterebilir. Bu veriyi analiz etmek, faturalandırma hatalarının ve tahsilat verimsizliklerinin finansal etkisini belirlemeye yardımcı olur.

Gelir kaybını ve finansal düzeltmeleri nicelendirir; faturalandırma yanlışlıklarının, sözleşmesel yükümlülüklerin veya şüpheli alacakların parasal etkisini belirlemeye yardımcı olur.

R1 RCM'deki hesap ayarlamaları veya ödeme kaydıyla ilgili işlem loglarında bulunur.

Bu nitelik, sağlık sistemi içinde bir hastaya atanan benzersiz kimliktir, genellikle Tıbbi Kayıt Numarası (MRN) olarak adlandırılır.\n\nBireysel hasta bakımı odak noktası olmasa da, Hasta Kimliği aynı hasta için zaman içindeki tekrar eden faturalandırma sorunlarını analiz etmek için kullanılabilir. Ayrıca, diğer hasta verileriyle bağlantılıysa, süreci hasta demografisine veya geçmişine göre bölümlere ayırmaya yardımcı olabilir ve belirli hasta gruplarını etkileyen sistemik sorunları ortaya çıkarabilir.

Faturalama olaylarının hasta düzeyinde analiz edilmesine olanak tanıyarak, belirli hastalar için birden fazla karşılaşmada tekrar eden sorunları veya kalıpları belirlemeye yardımcı olur.

Bu tanımlayıcı, R1 RCM'deki her görüşme ve taleple bağlantılı hasta demografik verilerinin temel bir parçasıdır.

CPT (Current Procedural Terminology) kodları gibi hizmet kodları, tıbbi, cerrahi ve teşhis prosedürleri ile hizmetlerini ödeme yapanlara geri ödeme için raporlamak üzere kullanılan standartlaştırılmış tıbbi kodlardır.\n\nHizmet koduna göre süreci analiz etmek, belirli bakım türleriyle ilgili faturalandırma sorunlarını belirlemek için temeldir. Hangi prosedürlerin en sık reddedildiğini, en uzun ödeme döngülerine sahip olduğunu veya en fazla yeniden işleme gerektirdiğini vurgulayarak, kodlama ve faturalandırma uygulamalarında hedeflenen iyileştirmelere olanak tanır.

Sunulan hizmet türüne göre süreç analizine olanak tanır, bu da belirli prosedürlerle ilişkili reddetme modellerini veya ödeme gecikmelerini belirlemek için anahtardır.

Bu bilgi, R1 RCM içindeki her ücret veya talep için kalem (line-item) düzeyinde bulunur.

Bu metrik, tek bir faturalandırma eventi (olayı) için gelir döngüsünün uçtan uca süresini ölçer. Bir kuruluşun sunulan bir hizmeti nakde dönüştürmesi için geçen toplam süreyi temsil eder.\n\nBu, finansal sağlık için kritik bir Ana Performans Göstergesidir (KPI). Bu süreyi analiz etmek, süreç hızlandırması için ana alanları belirlemeye yardımcı olur. Döngü süresini 'faturalandırma süresi' ve 'ödeme süresi' gibi bileşenlerine ayırarak, kuruluşlar nakit akışını iyileştirmek için en büyük fırsatları belirleyebilir.

Bu, nakit dönüşüm döngüsünün genel verimliliğini ölçen, kuruluşun nakit akışını doğrudan etkileyen kritik, üst düzey bir KPI'dır.

Bu hesaplanmış bir metriktir. Belirli bir Faturalandırma Olayı için 'Hizmet Sunuldu' etkinliğinin timestampi (zaman damgası) ile 'Ödeme Kaydedildi' etkinliğinin timestampi arasındaki zaman farkıdır.

Bu boole nitelik, talep gönderimi için bir RPA botu gibi yazılım otomasyonu tarafından yürütülen görevler ile bir çalışan tarafından manuel olarak gerçekleştirilen görevler arasında ayrım yapar.\n\nBu niteliki analiz etmek, otomasyon girişimlerinin etkisini ve etkinliğini anlamanın anahtarıdır. Otomatik ve manuel süreçlerin hızı, maliyeti ve hata oranlarını karşılaştırmaya olanak tanır, bu da yeni otomasyon fırsatlarını belirlemeye ve mevcut botların yatırım getirisini ölçmeye yardımcı olur.

Otomasyonun süreç verimliliği, maliyet ve kalite üzerindeki etkisini ölçmek için kritik olan insan ve sistem odaklı aktiviteler arasında ayrım yapar.

Bu, belirli kullanıcı kimliklerinin botlara ayrıldığı 'AssignedUser' alanından türetilebilir (örn: 'BOT_RPA01'). Alternatif olarak, bazı sistemlerde otomatikleştirilmiş işlemleri işaretlemek için özel bir alan bulunur.

Bu nitelik, vadesi geçmiş bir hesaptaki ödemeyi tahsil etme çabalarının sonucunu açıklar. Olası sonuçlar arasında 'Tamamen Ödendi', 'Anlaşıldı', 'Şüpheli Alacaklara Atandı' veya 'Çözülmedi' yer alır.\n\nTahsilat sonuçlarını izlemek, tahsilat sürecinin etkinliğini değerlendirmek için temeldir. Hangi etkinliklerin hangi sonuçlara yol açtığını analiz ederek, kuruluşlar tahsilat stratejilerini optimize edebilir, geri kazanım oranlarını iyileştirebilir ve tahsilat çabalarını ne zaman durduracakları ve bakiyeleri ne zaman silecekleri konusunda bilinçli kararlar verebilir. Bu, Tahsilat Etkinliği Performansı dashboardını destekler.

Vadesi geçmiş hesapların nihai çözümünü izleyerek tahsilat sürecinin etkinliğini ölçer, tahsilat stratejilerini optimize etmeye yardımcı olur.

Bu, büyük olasılıkla hasta hesabındaki veya R1 RCM içindeki özel bir tahsilat modülündeki bir durum alanıdır.

Bu nitelik, Process Mining analizi sırasında tipik olarak hesaplanan bir boole bayrağıdır. Bir etkinlik önceki bir adımın tekrarıysa veya bir hatanın düzeltilmesini gösteren bir dizinin parçasıysa, örneğin 'Talep Reddedildi' sonrasındaki herhangi bir etkinlikte 'true' olur.\n\nYeniden işlemeyi belirlemek, Process Mining'in en güçlü yeteneklerinden biridir. Bir süreçte boşa harcanan çaba, zaman ve kaynak miktarını nicelendirir. Yeniden işlemeyi işaretleyerek, kuruluşlar iyileştirme çabalarını, buna neden olan hataları ilk etapta önlemeye odaklayabilir ve bu da önemli verimlilik artışlarına yol açar.

Talep reddi gibi yeniden işleme sıklığını ve etkisini nicelendirmeye yardımcı olur, verimsizlikleri ve boşa harcanan çabayı azaltmak için hedeflenen analize olanak tanır.

Bu, kaynak sistemde bir alan değildir. Aynı case (durum) için 'Talep Gönderildi' etkinliğinin birden fazla kez gerçekleştiğini tespit etmek gibi etkinlik dizisine dayanarak Process Mining aracı tarafından hesaplanır.