Gelir döngüsü yönetimi veri şablonunuz
Gelir döngüsü yönetimi veri şablonunuz
Bu, Gelir döngüsü yönetimi için genel amaçlı Process Mining veri Templateimizdir. Daha ayrıntılı yönlendirme için sisteme özel Templatelerimizi kullanın.
Belirli bir sistem seçin- Process Mining için tüm RCM sistemlerinde kullanılabilir.
- Etkili bir Event Log oluşturmak için gereken temel öznitelikler ve etkinlikler.
- Güvenilir süreç analizi ve optimizasyonu için temel bir kaynak.
Gelir döngüsü yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite adı ActivityName | Belirli bir faturalama olayı için gelir döngüsü sürecinde gerçekleşen adımın, görevin veya olayın adı. | ||
| Açıklama Aktivite adı, gelir döngüsündeki belirli bir eylemi veya kilometre taşını tanımlar. Örnekler arasında 'Hizmet sunuldu', 'Talep gönderildi', 'Ödeme bildirimi alındı', 'Ödeme kaydedildi' ve 'Hesap zarara yazıldı' yer alır. Her aktivite, zaman ve kaynak gerektiren bir süreç adımını temsil eder. Bu öznitelik, süreç haritasındaki düğümleri tanımladığı için Process Mining açısından temel önemdedir. Aktivitelerin sırasını, sıklığını ve süresini inceleyerek gerçek süreç akışını görselleştirebilir, tasarlanan modelle karşılaştırabilir; taleplerin reddedilmesi gibi sapmaları, yeniden çalışma döngülerini ve verimsizlikleri belirleyebilirsiniz. Neden önemli? Bu öznitelik, sürecin adımlarını tanımlar. Süreç haritasını keşfetmek ve görselleştirmek, yeniden çalışmayı belirlemek ve süreç uyumluluğunu incelemek için gereklidir. Nereden alınır? Genellikle olay günlüklerinde ve işlem tablolarında bulunur ya da faturalama veya talep modülündeki durum değişikliği kayıtlarından elde edilir. Örnekler Talep gönderildiÖdeme işlendiRet için yeniden çalışma başladıHasta hesap özeti gönderildi | |||
| Faturalama Olayı Kimliği BillingEventId | Ücret oluşturulmasına yol açan tek bir hizmet veya ürün teslimatının benzersiz tanımlayıcısıdır. Gelir döngüsü sürecinde temel vaka tanımlayıcısı olarak kullanılır. | ||
| Açıklama Faturalama Olayı Kimliği, ilk ücret kaydından son ödeme veya zarara yazma işlemine kadar ücretlendirilebilir her hizmet örneğine atanan benzersiz bir anahtardır. Belirli bir hizmet karşılaşmasıyla ilgili talep oluşturma, gönderme, ret ve ödeme kaydı gibi tüm etkinlikleri birbirine bağlayan ana referans görevi görür. Process Mining’de bu öznitelik, her faturalama olayının uçtan uca yolculuğunu yeniden oluşturmak için gereklidir. Analistler, ilgili tüm etkinlikleri tek bir Faturalama Olayı Kimliği altında gruplayarak süreç akışlarını görselleştirebilir, darboğazları belirleyebilir, çevrim sürelerini ölçebilir ve farklı vakaların nasıl ele alındığını anlayabilir. Gelir döngüsündeki vaka odaklı tüm analizlerin temelini oluşturur. Neden önemli? İlgili tüm etkinlikleri birbirine bağlayan temel vaka tanımlayıcısıdır. Her ücretlendirilebilir hizmet için gelir döngüsünün tamamını yeniden oluşturup analiz etmenizi sağlar. Nereden alınır? Bu genellikle faturalama işlemi veya finansal olay tablolarındaki birincil anahtardır. Örnekler BE-2024-001234INV-987654ACCN-456789012 | |||
| Olay zaman damgası EventTimestamp | Belirli bir aktivitenin sistemde kaydedildiği kesin tarih ve saat. | ||
| Açıklama Olay zaman damgası, bir aktivitenin gerçekleştiği veya kayda geçtiği zamanı belirtir. Bir vakadaki tüm olayların kronolojik bağlamını sunarak gelir döngüsünün başlangıcından sonuna kadar zaman çizelgesini oluşturur. Zaman damgaları, Process Mining performans analizinin temelini oluşturur. Toplam çevrim süresi, belirli aktiviteler arasındaki süre ve bekleme süreleri gibi temel KPI’ları hesaplamak için kullanılır. Kuruluşlar zaman damgalarını inceleyerek vakaların en uzun süre beklediği darboğazları belirleyebilir, hizmet seviyesi anlaşmalarına uyumu ölçebilir ve sürecin zaman içindeki işleyişini anlayabilir. Neden önemli? Çevrim sürelerini hesaplamak, darboğazları belirlemek ve sürecin performansıyla verimliliğini incelemek için gereken kronolojik veriyi sağlar. Nereden alınır? Bu bilgi genellikle işlem günlüklerinde, denetim izlerinde veya olay tablolarındaki 'oluşturulma tarihi' ya da 'durum değişikliği tarihi' alanında bulunur. Örnekler 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| Kaynak sistem SourceSystem | Olay verilerinin çıkarıldığı bilgi sistemi, uygulama veya modül. | ||
| Açıklama Kaynak sistem özniteliği, belirli bir olaya ait verinin kaynağını gösterir. Karmaşık bir BT ortamında gelir döngüsü süreci çoğu zaman hizmet sunumu için Elektronik Sağlık Kaydı (EHR) sistemi, talep gönderimi için özel bir faturalama sistemi ve tahsilat için ayrı bir platform gibi birden fazla sisteme yayılır. Verinin hangi sistemden geldiğini bilmek, veri doğrulama ve sorun giderme açısından yararlıdır; ayrıca süreçteki parçalanmayı anlamanıza yardımcı olur. Sistemler arasındaki tutarsızlıkları veya farklı uygulamalarda yönetilen süreç adımlarını ortaya çıkarabilir. Bu durumlar veri aktarımında gecikmelere ya da hatalara yol açabilir. Böylece süreci destekleyen genel BT mimarisinin entegrasyonunu ve verimliliğini değerlendirebilirsiniz. Neden önemli? Farklı BT sistemlerine yayılan süreç parçalanmasını anlamaya yardımcı olur; verileri doğrulamak ve sisteme özgü darboğazları belirlemek için önemlidir. Nereden alınır? Bu bilgi genellikle veri dışa aktarımlarında standart bir alan olarak bulunur veya verinin alındığı kaynak tablo ya da dosyaya göre belirlenebilir. Örnekler Epic ResoluteOracle HealthR1 RCM PlatformWaystar | |||
| Son veri güncellemesi LastDataUpdate | Bu olay kaydındaki verilerin kaynak sistemden en son yenilendiği veya çıkarıldığı zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, verilerin kaynak sistemden en son ne zaman alındığını kaydeder. İncelenen verilerin ne kadar güncel olduğunu ve ne zaman yenilendiğini anlamak için önemli bir meta veri alanıdır. Veri hattındaki gecikmeyi yansıtır ve Process Mining analizinin ne kadar güncel olduğunu gösterir. Process Mining Dashboardlarında ve analizlerinde son veri güncellemesi zaman damgası, verilerin güncelliği hakkında bilgi verir. Operasyonları izlerken görünümün beş dakika önceki mi yoksa önceki geceden mi kaldığını bilmek önemlidir. Bu bilgi, kullanıcıların beklentilerini yönetmeye ve kararların verinin yaşı bilinirken alınmasına yardımcı olur. Neden önemli? Verilerin ne kadar güncel olduğunu ve zamanında sunulup sunulmadığını gösterir; analizlerin ve kararların hangi zaman aralığını kapsadığı anlaşılır. Nereden alınır? Bu bilgi genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenir ve olay günlüğünde meta veri sütunu olarak saklanır. Örnekler 2024-03-15T02:00:00Z2024-03-15T03:00:00Z2024-03-15T04:00:00Z | |||
| Düzeltme tutarı AdjustmentAmount | Hesap bakiyesine uygulanan düzeltmelerin, zarara yazılan tutarların veya sözleşme indirimlerinin parasal değeri. | ||
| Açıklama Düzeltme tutarı, sözleşme koşulları, indirimler veya zarara yazma gibi nedenlerle ödeyiciden ya da hastadan tahsil edilmesi beklenmeyen faturalanmış tutar bölümünü gösterir. Bu düzeltmeler toplam alacakları azaltır ve gelir döngüsünün olağan bir parçasıdır. Düzeltme tutarlarını ve nedenlerini incelemek, gelir bütünlüğünü anlamak açısından önemlidir. Yüksek veya beklenmedik düzeltme tutarları; ücret kaydı, kodlama ya da sözleşme yönetimindeki sorunlara işaret edebilir. Process Mining ile hangi süreç varyantlarının veya belirli aktivitelerin daha yüksek düzeltme oranlarına yol açtığını belirleyebilir, gelirin tahsil edilmesini en üst düzeye çıkarmak için temel nedenleri hedefli biçimde inceleyebilirsiniz. Neden önemli? Zarara yazılan tutarları ve sözleşme indirimlerini izleyerek gelir kaybını incelemenize yardımcı olur; sözleşme veya faturalama süreçlerindeki olası sorunları ortaya çıkarır. Nereden alınır? Bu değer genellikle finansal düzeltme tablolarında veya ödeme kayıt modüllerinde tutulur. Örnekler 29.50500.75100.001500.00 | |||
| Faturalanan tutar BilledAmount | Herhangi bir düzeltme veya ödeme yapılmadan önce faturalandırılan hizmetin ya da ürünün brüt parasal değeri. | ||
| Açıklama Faturalanan tutar, bir talep veya faturada bildirilen hizmetlerin toplam bedelidir. Faturalama olayının başlangıçtaki finansal değerini oluşturur; ödemeler ve düzeltmeler gibi sonraki tüm finansal işlemler bu tutara göre değerlendirilir. Process Mining kapsamında faturalanan tutarı incelemek, süreç verimsizliklerinin finansal etkisini anlamanın temel yollarından biridir. Vakaları yüksek ve düşük değerli olarak gruplandırarak belirli süreç sorunlarının yüksek gelirli talepleri orantısız biçimde etkileyip etkilemediğini görebilirsiniz. Bu tutarı çevrim süresi veya ret oranı gibi metriklerle karşılaştırmak, en büyük finansal sonuçlara yol açan sorunlara öncelik vermenize yardımcı olur. Neden önemli? Vakanın başlangıçtaki finansal değerini belirler; gecikme ve ret gibi süreç verimsizliklerinin mali etkisini incelemenizi sağlar. Nereden alınır? Bu temel finansal öznitelik, ücret kaydı, faturalama veya talep işlem tablolarında bulunur. Örnekler 150.002500.75500.0010000.00 | |||
| Hizmet kategorisi ServiceCategory | Yatarak tedavi, ayakta tedavi veya radyoloji gibi sunulan hizmetin kategorisi, türü ya da sınıflandırması. | ||
| Açıklama Hizmet kategorisi, hastaya sunulan bakımın veya hizmetin türünü sınıflandırır. 'Yatarak tedavi' ve 'Ayakta tedavi' gibi üst düzey bir sınıflandırma olabileceği gibi 'Cerrahi', 'Acil' veya 'Laboratuvar' gibi daha özel bir departman kategorisi de olabilir. Farklı hizmet kategorilerinin faturalama kuralları, ödeyici gereklilikleri ve süreç akışları da farklı olabilir. Anlamlı bir analiz için gelir döngüsü sürecini hizmet kategorisine göre gruplandırmak önemlidir. Kuruluşlar farklı hizmet alanlarının performansını karşılaştırabilir; örneğin cerrahi işlemlerdeki ret oranının muayenelere göre daha yüksek olup olmadığını görebilir. Bu ayrıntı düzeyi, sorunları belirli hizmet alanlarının operasyonel koşullarına göre saptamanıza ve iyileştirme çalışmalarını uyarlamanıza yardımcı olur. Neden önemli? Farklı hizmet alanlarının performansını karşılaştırmanızı sağlar; belirli bakım türlerine özgü verimlilik, ret oranı ve ödeme süresi farklılıklarını ortaya çıkarır. Nereden alınır? Bu bilgi genellikle ücret ayrıntı kayıtlarında bulunur veya hasta sınıfı, departman ya da prosedür kodlarından elde edilebilir. Örnekler Yatarak tedaviAyakta tedaviAcilRadyolojiCerrahi işlem | |||
| Ödeyici adı PayerName | Ödemeden sorumlu sigorta şirketinin, kamu kurumunun veya başka bir üçüncü taraf ödeyicinin adı. | ||
| Açıklama Ödeyici adı, geri ödeme talebinin gönderildiği birincil kuruluşu belirtir. Ödeyiciler arasında Aetna veya UnitedHealthcare gibi özel sigorta şirketleri, Medicare veya Medicaid gibi kamu programları ve başka kuruluşlar bulunabilir. Her ödeyicinin kendine özgü kuralları, gönderim gereklilikleri ve ödeme alışkanlıkları vardır. Bu öznitelik, gelir döngüsü performansını incelemek için önemlidir. Süreci ödeyiciye göre gruplandırarak hangi ödeyicilerde ret oranlarının ve ödeme sürelerinin en yüksek olduğunu ya da ek bilgi taleplerinin en sık geldiğini belirleyebilirsiniz. Bu analiz; sözleşmeleri yeniden müzakere etmek, gönderim süreçlerini belirli ödeyicilere göre uyarlamak ve ret yönetimi çalışmalarını en çok ihtiyaç duyulan alanlara yöneltmek gibi hedefli iyileştirmelere olanak tanır. Neden önemli? Ret oranı ve ödeme süresi gibi performans metriklerini ödeyiciye göre gruplandırmanızı sağlar. Bu bilgi, hedefli iyileştirmeler ve sözleşme görüşmeleri için önemlidir. Nereden alınır? Bu bilgi genellikle faturalama olayıyla ilişkili hasta kaydı, sigorta veya talep verilerinde bulunur. Örnekler AetnaCignaMedicareUnitedHealthcare | |||
| Ret nedeni kodu DenialReasonCode | Ödeyicinin bir talebi neden reddettiğini belirten standart kod ve açıklama. | ||
| Açıklama Ödeyici gönderilen bir talebi reddettiğinde, neden ödeme yapılmadığını açıklamak için ret nedeni kodu verir. Bu kodlar genellikle Talep Düzeltme Neden Kodları (CARC) gibi sektör standartlarına uyar ve 'Hizmet kapsam dışı', 'Yinelenen talep' veya 'Ek bilgi gerekli' gibi belirli sorunları belirtir. Bu öznitelik, gelir döngüsünde temel neden analizi için en yararlı göstergelerden biridir. Farklı ret nedenlerinin sıklığını ve finansal etkisini inceleyerek retlere yol açan önceki süreç adımlarındaki aksaklıkları belirleyebilirsiniz. Örneğin, 'Yanlış hasta bilgisi' nedeniyle çok sayıda talebin reddedilmesi, hasta kayıt sürecindeki sorunlara işaret eder. Bu bilgi, gelecekteki retleri önlemek ve ilk gönderimde ödeme oranını artırmak için veriye dayalı iyileştirmeler yapmanızı sağlar. Neden önemli? Talep retlerinin temel nedenlerini incelemek için önemlidir. Gelecekteki gelir kayıplarını önlemek amacıyla sürecin başlangıç ve orta aşamalarında hedefli iyileştirmeler yapmanızı sağlar. Nereden alınır? Bu bilgi, ödeyicilerden alınan elektronik ödeme bildirimi (ERA) veya sigorta kapsamı açıklaması (EOB) dosyalarından elde edilir. Örnekler CO-16: Talep/hizmet bilgileri eksikPR-97: Bu hizmetin karşılığı başka bir hizmet için yapılan ödemeye dahildirOA-18: Yinelenen talep/hizmetCO-22: Yardımların koordinasyonu kapsamında bu bakım başka bir ödeyici tarafından karşılanabilir | |||
| Sorumlu departman ResponsibleDepartment | Aktiviteyi gerçekleştirmekten sorumlu departman, ekip veya işlevsel birim. | ||
| Açıklama Bu öznitelik, 'Hasta kabul', 'Kodlama', 'Faturalama' veya 'Tahsilat' gibi belirli bir süreç adımıyla ilişkili kurumsal birimi gösterir. İşlerin ekipler arasında nasıl dağıtıldığını ve devredildiğini anlamanıza yardımcı olur. Süreci departman bazında incelemek, işlevler arası iş birliğini anlamak ve ekipler arasındaki devir teslim noktalarında oluşan darboğazları belirlemek için önemlidir. Yöneticiler, belirli süreç varyantlarında hangi departmanların yer aldığını görebilir, departman verimliliğini ölçebilir ve kaynakları daha etkili dağıtabilir. Bu analiz, gelir döngüsünün tamamını etkileyebilecek departman kaynaklı sistemik sorunları ortaya çıkarabilir. Neden önemli? Departmanlar arasındaki darboğazları belirlemeye ve işlevsel birimlerin performansını incelemeye yardımcı olur; ekipler arası iş birliğini geliştirme fırsatlarını ortaya çıkarır. Nereden alınır? Bu bilgi işlem verilerinde bulunabilir veya sorumlu kullanıcıyla ilişkili ana verilerden elde edilebilir. Örnekler Faturalama departmanıKodlama hizmetleriRet yönetimiTahsilat | |||
| Sorumlu kullanıcı ResponsibleUser | Aktiviteyi gerçekleştiren kullanıcının, çalışanın veya otomatik aracının kimliği. | ||
| Açıklama Sorumlu kullanıcı özniteliği, bir süreç adımını gerçekleştiren kişiyle veya sistemle ilişkilendirir. Bu kişi tıbbi kodlama yapan bir kodlama uzmanı, talep gönderen bir faturalama uzmanı ya da ödemeyi kaydeden otomatik bir bot olabilir. Kullanıcıyı izlemek, süreç analizine kişi veya sistem odaklı bir boyut kazandırır. Kullanıcı veya ekip bazında süreç performansını inceleyerek eğitim fırsatlarını görebilir, yüksek performans gösteren çalışanları belirleyebilir ve iş yükünü dengeli dağıtabilirsiniz. Bu bilgi, uyumluluk ve denetim açısından da önemlidir; gerçekleştirilen her işlem için sorumluluğun açıkça belirlenmesini sağlar. Böylece kaynak performansını ve kullanımını ayrıntılı biçimde inceleyebilirsiniz. Neden önemli? Ekip ve kişi performansını, iş yükü dağılımını ve otomasyon oranlarını incelemenizi sağlar. Böylece kaynak verimliliğini değerlendirebilir ve eğitim ihtiyaçlarını belirleyebilirsiniz. Nereden alınır? Genellikle işlem günlüklerinde veya denetim izlerinde 'Kullanıcı kimliği', 'Çalışan kimliği' ya da 'İşlemci' alanlarında bulunur. Örnekler john.doejane.smithAUTO-POSTER-BOTU123456 | |||
| Düzeltme nedeni AdjustmentReason | Sözleşme indirimi veya tahsil edilemeyen alacağın zarara yazılması gibi bir finansal düzeltmenin nedeni. | ||
| Açıklama Ret nedenine benzer şekilde düzeltme nedeni, faturalanan tutarın bir bölümünün neden silindiğini veya düzeltildiğini açıklar. Düzeltmenin ödeyiciyle yapılan sözleşmeden, hayır amaçlı bakım politikasından, düşük bakiyenin zarara yazılmasından ya da faturalama hatasının düzeltilmesinden kaynaklanıp kaynaklanmadığını gösterir. Düzeltme nedenlerini incelemek, gelir bütünlüğü ve finansal performans hakkında bilgi verir. Beklenen sözleşme düzeltmeleriyle iç hatalardan kaynaklanan ve önlenebilir zararları birbirinden ayırmanıza yardımcı olur. Analistler, süreç haritasını belirli düzeltme nedenlerine göre filtreleyerek önlenebilir gelir kaybına yol açan süreç zayıflıklarını belirleyebilir ve iyileştirme çalışmalarını bu alanlara yöneltebilir. Neden önemli? Finansal düzeltmelerin bağlamını sunarak sözleşme yükümlülükleriyle süreç hatalarından kaynaklanan önlenebilir gelir kaybını ayırt etmenize yardımcı olur. Nereden alınır? Faturalama veya hasta muhasebesi sistemindeki finansal işlem tablolarında bulunur; genellikle düzeltme ya da zarara yazma işlemleriyle ilişkilidir. Örnekler Sözleşme indirimiDüşük bakiyenin zarara yazılmasıTahsil edilemeyen alacakFaturalama hatası düzeltmesi | |||
| Hasta kimliği PatientId | Hizmet alan hastaya ait benzersiz kimlik. | ||
| Açıklama Hasta kimliği, sağlık sisteminin ana hasta dizininde her hastaya atanan benzersiz anahtardır. Hastanın zaman içindeki tüm klinik ve finansal işlemlerini bu kimlik birbirine bağlar. Faturalama olayı kimliği tek bir hizmete ait vakayı gösterirken hasta kimliği, aynı hastanın birden fazla işlemini birlikte incelemenizi sağlar. Böylece tekrarlanan kayıt hataları veya hizmet kullanım örüntüleri gibi sorunları belirleyebilirsiniz. Ayrıca hastanın tüm finansal yolculuğunu inceleyerek hastanın mali sorumluluğunu ve bağlılığını anlamanıza yardımcı olur. Neden önemli? Aynı hastaya ait birden fazla faturalama olayını birlikte incelemenizi sağlar; tekrarlanan sorunları belirlemeye ve hastanın genel finansal yolculuğunu anlamaya yardımcı olur. Nereden alınır? Bu, neredeyse tüm klinik ve finansal sistemlerde bulunan temel bir kimlik bilgisidir ve hasta kayıt veya EHR sisteminden alınır. Örnekler MRN-100345PAT-987654321202400567 | |||
| Hesap durumu AccountStatus | Gelir döngüsündeki faturalama hesabının 'Faturalandı', 'Ödendi' veya 'Tahsilatta' gibi mevcut durumu. | ||
| Açıklama Hesap durumu, faturalama olayının yaşam döngüsünde belirli bir anda hangi aşamada olduğunu gösterir. En son aktivitenin sonucunu yansıtarak hesabın açık ve ödeme bekliyor, kapalı, tahsilata gönderilmiş veya başka bir durumda olduğunu belirtir. Process Mining aktivitelerin akışını yeniden oluştururken hesap durumu özniteliği, vakaları mevcut durumlarına göre filtrelemek ve gruplandırmak için yararlıdır. Ödeyiciden yanıt bekleyen alacakların toplam tutarı veya yakın zamanda tahsilat kuruluşuna gönderilen hesap sayısı gibi farklı aşamalardaki hesapların hacmini ve değerini göstermesi gereken operasyonel izleme Dashboardlarında özellikle kullanışlıdır. Neden önemli? Vakaların mevcut durumunu gösterir. Operasyonel Dashboardlarda ve hesapları yaşam döngüsündeki aşamalarına göre gruplandırarak incelemede kullanışlıdır. Nereden alınır? Bu bilgi genellikle hasta muhasebesi sistemindeki ana hasta hesabı veya faturalama olayı kaydında bir durum alanı olarak bulunur. Örnekler Faturalandı, ödeyici bekleniyorTamamı ödendiReddedildiTahsilata gönderildiKapalı, zarara yazıldı | |||
| Ödenen tutar PaidAmount | Faturalanan hizmetler için ödeyicilerden ve hastadan alınan toplam para tutarı. | ||
| Açıklama Ödenen tutar, belirli bir faturalama olayına kaydedilen tüm ödemelerin toplamıdır. Birincil ve ikincil sigorta ödeyicilerinden gelen ödemelerin yanı sıra hastanın yaptığı ödemeleri de kapsar. Sunulan hizmetler karşılığında tahsil edilen gerçek nakit tutarını gösterir. Gelir döngüsünün finansal başarısını ve verimliliğini ölçmek için ödenen tutarı incelemek önemlidir. Ödenen tutarı faturalanan tutarla karşılaştırarak net gelir ve tahsilat oranları hakkında bilgi edinebilirsiniz. Process Mining analizinde bu öznitelik, farklı süreç yollarının finansal sonuçlarını ölçmenize yardımcı olur. Ayrıca hangi taleplerin zamanında ve eksiksiz ödendiğini, hangilerinin ödenmediğini belirlemek için kullanılabilir. Neden önemli? Bir vaka için tahsil edilen gerçek nakit tutarını ölçer. Tahsilat etkinliğini ve sürecin genel finansal performansını değerlendirmek için önemlidir. Nereden alınır? Bu bilgi, ödeme kaydı veya nakit tahsilat işlem tablolarında bulunur. Örnekler 120.502000.000.00450.25 | |||
| Ödenmemiş bakiye OutstandingBalance | Belirli bir zamandaki faturalama olayına ait kalan ödenmemiş bakiye. | ||
| Açıklama Ödenmemiş bakiye, faturalama olayı için tahsil edilmesi gereken kalan tutarı gösterir. Genellikle faturalanan tutardan ödenen ve düzeltme yapılan tutarlar çıkarılarak hesaplanır. Vakanın yaşam döngüsü boyunca ödeme ve düzeltmeler kaydedildikçe bu değer değişir. Bu öznitelik, alacakların durumunu gösteren temel bir ölçüttür. Process Mining kapsamında sürecin farklı aşamalarındaki ödenmemiş bakiyeyi inceleyerek alacakların yaşlandırılmasını yönetebilir ve tahsilat çalışmalarına öncelik verebilirsiniz. Hangi vaka türlerinin veya süreç yollarının yüksek bakiye bırakma eğiliminde olduğunu belirleyerek ödeme ya da ret çözümündeki sorunları saptayabilirsiniz. Neden önemli? Alacakları ve tahsilat etkinliğini ölçen temel bir göstergedir; takip çalışmalarına öncelik vermenize ve alacakların yaşlandırılmasını incelemenize yardımcı olur. Nereden alınır? Genellikle faturalanan, ödenen ve düzeltilen tutarlardan hesaplanır. Alacaklar veya hasta muhasebesi sisteminde bir alan olarak da saklanabilir. Örnekler 50.000.00125.308500.00 | |||
| Talep kimliği ClaimId | Ödeyiciye gönderilen sigorta talebine atanan benzersiz kimlik. | ||
| Açıklama Talep kimliği, sigorta şirketine gönderilen faturaya ait benzersiz bir tanımlayıcıdır. Bir faturalama olayı için birincil, ikincil ve üçüncül ödeyicilere ayrı talepler gönderilmesi veya bir talebin düzeltilip yeniden gönderilmesi gerekebilir. Talep kimliğini izlemek, ödeyiciyle yürütülen sürecin ayrıntılarını anlamak açısından önemlidir. Yeniden gönderimlerin yol açtığı yeniden çalışma döngülerini incelemenizi ve ödeyiciye gönderilen belirli bir faturanın durumunu izlemenizi sağlar. Süreci talep kimliğine göre incelemek, talep gönderimi ve sonuçlandırma yaşam döngüsünü yalnızca faturalama olayına bakmaktan daha ayrıntılı gösterir. Neden önemli? Talep gönderimlerini ve yeniden gönderimlerini ayrıntılı biçimde izlemenizi sağlar; ödeyicilerle etkileşimleri ve yeniden çalışma döngülerini incelemenize yardımcı olur. Nereden alınır? Bu kimlik, talep oluşturulduğunda faturalama sistemi tarafından üretilir ve talep yönetimi tablolarında saklanır. Örnekler CLM-2024-555-1239876543210-01TCN-A1B2C3D4E5 | |||
Gelir döngüsü yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Faturalama olayı kapatıldı | Faturalama olayı tamamen çözüme kavuşmuş, ödenmemiş bakiyesi sıfırlanmış ve başka bir işlem beklenmiyordur. Bu durum ödemeler, düzeltmeler, zarara yazma işlemleri veya bunların bir arada uygulanmasıyla oluşabilir. | ||
| Neden önemli? Bu etkinlik sürecin sonunu işaret eder ve uçtan uca toplam çevrim süresinin hesaplanmasını sağlar. Faturalama olayının tahsilatla mı yoksa zarara yazılarak mı sonuçlandığını doğrular. Nereden alınır? Bu durum çoğu zaman hesap bakiyesinin sıfırlanmasından anlaşılır. Bazı sistemlerde açık bir 'Kapalı' durumu veya hesap kaydında kapanış tarihi alanı bulunabilir. Kaydedin Faturalama olayında bakiyeyi sıfırlayan son finansal işlemin zaman damgasını belirleyerek bu olayı saptayın. Olay türü inferred | |||
| Hizmet sunuldu | Bu etkinlik, faturalama olayının başlangıcını işaret eder. Hastaya klinik hizmetin sunulduğu zamanı gösterir ve belirli bir hasta karşılaşması için tüm gelir döngüsü sürecini başlatır. | ||
| Neden önemli? Bu, uçtan uca sürecin temel başlangıç noktasıdır ve toplam gelir döngüsü süresinin ölçülmesini sağlar. Klinik hizmetin sunulmasıyla faturalama faaliyetlerinin başlaması arasındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? Bu bilgiler genellikle klinik sistemlerden, randevu planlama sistemlerinden veya elektronik sağlık kayıtlarından alınır. İmzalanmış bir klinik nottan, tamamlanmış bir prosedür kaydından ya da hasta taburcu kaydından elde edilebilir. Kaydedin Klinik karşılaşmanın tamamlandığı, hizmetin sunulduğu veya hastanın taburcu edildiği tarihe ait zaman damgasını kaydedin. Olay türü explicit | |||
| Ödeme işlendi | Alınan ödeme, hastanın hesabına resmen uygulanır ve belirli hizmet kalemlerine dağıtılır. Bu işlem, bakiyeyi alacak hesaplarından nakde aktarır ve ödenmemiş tutarı azaltır. | ||
| Neden önemli? Bu, ödemenin ödeme yapan kuruluştan tahsil edildiğini doğrulayan önemli bir başarı aşamasıdır. Ödeme kaydının işlenmesindeki gecikmeler, alacak yaşlandırma raporlarının ve nakit akışı raporlamasının doğruluğunu bozabilir. Nereden alınır? Bu, hasta muhasebesi sisteminin defterine kaydedilen açık bir finansal işlemdir. Her ödeme uygulamasının kendine ait işlem tarihi ve saati bulunmalıdır. Kaydedin Ödeme uygulamasının veya nakit kayıt günlüğünün işlem zaman damgasını kullanın. Olay türü explicit | |||
| Talep gönderildi | Bu etkinlik, oluşturulan talebin değerlendirilmek üzere sigorta şirketine veya ödeme yapan kuruluşa elektronik ya da basılı olarak gönderilmesini işaret eder. Sunulan hizmetler için resmî ödeme talebini ifade eder. | ||
| Neden önemli? Bu etkinliği izlemek, Hizmetten Faturaya Çevrim Süresini ölçmek ve talebin oluşturulmasıyla gönderilmesi arasındaki gecikmeleri belirlemek açısından önemlidir. Faturalama olayının alacak hesaplarına resmen geçtiği temel aşamayı gösterir. Nereden alınır? Bu olay genellikle talep işlem günlüklerine veya takas odası arayüz tablolarına kaydedilir. Başarılı iletimi gösteren belirli bir durum güncellemesi de bulunabilir. Kaydedin Talep durumunun 'Gönderildi', 'İletildi' veya eşdeğer bir duruma geçtiği zaman damgasını kaydedin. Olay türü explicit | |||
| Talep reddedildi | Ödeme yapan kuruluşun bir talebi veya belirli kalemleri reddederek ödemenin yapılmasını engellemesini ifade eder. Bu durum genellikle hizmet sağlayıcının ödeme yapan kuruluştan gelen ödeme bildirimini alıp işlemesiyle belirlenir. | ||
| Neden önemli? Talep retlerini belirlemek; gelir kaybını, ret oranlarını ve ret yönetimi sürecinin etkinliğini analiz etmek için temel önemdedir. Retler, yeniden çalışma döngülerini ve itiraz süreçlerini başlatan başlıca nedendir. Nereden alınır? Bu olay genellikle ödeme bildirimi verilerinde, özellikle ret olduğunu gösteren talep düzeltme neden kodları (CARC) incelenerek bulunur. Kaydedin Talep veya hizmet kalemiyle ilişkili ret kodlarını bulmak için ödeme bildirimi verilerini ayrıştırarak bu olayı belirleyin. Olay türü inferred | |||
| Hasta hesap özeti gönderildi | Tüm sigorta ödemeleri ve düzeltmeler kaydedildikten sonra fatura özeti oluşturulur ve hastanın ödemesi gereken tutar için hastaya gönderilir. Böylece tahsilatın odağı kurumsal ödeme yapan kuruluştan kişiye kayar. | ||
| Neden önemli? Bu etkinlik, gelir döngüsünün hastanın kendi ödediği kısmını başlatır. Bunu izlemek, hastalardan tahsilat stratejilerinin etkinliğini analiz etmeye ve hastalara fatura gönderilene kadar geçen süreyi ölçmeye yardımcı olur. Nereden alınır? Bu, hasta faturalama veya iletişim modülünün kaydettiği açık bir olaydır. Sistem, her hesap özetinin oluşturulduğu veya gönderildiği tarihi kaydetmelidir. Kaydedin Hasta hesap özeti geçmişi günlüğündeki oluşturulma veya gönderilme tarihini kullanın. Olay türü explicit | |||
| Hesap bakiyesi düzeltildi | Sözleşme düzeltmesi, düşük bakiyenin silinmesi veya iyi niyet indirimi gibi, ödeme içermeyen ve hesap bakiyesini değiştiren bir işlemdir. Ödeme yapan kuruluşla yapılan sözleşmeler veya iç politikalar doğrultusunda hesabı mutabık hâle getirmek için bu işlemler gerekir. | ||
| Neden önemli? Düzeltmeler, gelir farklılıklarının başlıca nedenlerinden biridir. Düzeltme etkinliklerini ve nedenlerini analiz etmek; kârlılığı, ödeme yapan kuruluşlarla yapılan sözleşmelerin performansını ve gelir kayıtlarının doğruluğunu anlamaya yardımcı olur. Nereden alınır? Bunlar, hasta defterine ayrı finansal işlemler olarak kaydedilir. Her işlemde düzeltme nedenini belirten özel bir işlem kodu veya türü bulunur. Kaydedin Hesap bakiyesini değiştiren, ödeme veya ücret kaydı içermeyen finansal işlemlerin tarihini kaydedin. Olay türü explicit | |||
| Hesap zarara yazıldı | Tüm tahsilat girişimleri sonuçsuz kalmış ve kalan hesap bakiyesinin tahsil edilemeyeceğine karar verilmiştir. Bakiye sıfırlanır ve tahsil edilemeyen alacak olarak sınıflandırılır; bu da nihai bir gelir kaybını ifade eder. | ||
| Neden önemli? Bu etkinlik, gelir kaybını gösteren önemli bir finansal olaydır. Zarara yazılan tutarları analiz etmek, nihai tahsilat başarı oranını ve tahsil edilemeyen borçların kaynaklarını anlamak için gereklidir. Nereden alınır? Bu, genellikle 'Tahsil edilemeyen alacak zararı' veya 'Tahsilat kuruluşuna gönderildi' gibi belirli bir neden kodu taşıyan açık bir finansal işlemdir. Kaydedin Kalan bakiyeyi tahsil edilemeyen alacak olarak sınıflandıran düzeltmenin işlem tarihini kaydedin. Olay türü explicit | |||
| Kodlama tamamlandı | Tıbbi kodlayıcıların kaydedilen ücretlere ICD veya CPT kodları gibi standart klinik kodlar atadığını gösterir. Bu adım, hizmetlerin ödeme yapan kuruluşların anlayıp değerlendirebileceği biçimde ifade edilmesini sağlar. | ||
| Neden önemli? Bu etkinlik, talep doğruluğu için gereklidir ve sık karşılaşılan darboğazlardan biridir. Kodlama aşamasının süresini ölçmek, kodlayıcı verimliliğini artırma ve taleplerin beklemesini azaltma fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Bu bilgi genellikle faturalama olayındaki bir durum değişikliğiyle veya iş kuyruğundaki kodlama görevinin tamamlandı olarak işaretlendiği zaman damgasıyla kaydedilir. Kaydedin Karşılaşmanın kodlama durumunun 'Tamamlandı' olarak ayarlandığı veya son kodun onaylandığı zaman damgasını belirleyin. Olay türü explicit | |||
| Ödeme bildirimi alındı | Sistem, gönderilen taleple ilgili olarak ödeme yapan kuruluştan çoğunlukla Elektronik Ödeme Bildirimi (ERA) dosyası biçiminde yanıt alır. Bu yanıt, her hizmet kalemi için ne kadar ödeme yapıldığını, hangi kalemlerin reddedildiğini veya düzeltildiğini ayrıntılı olarak gösterir. | ||
| Neden önemli? Bu önemli olay, ödeme kaydının işlenmesi, ret yönetimi veya düzeltmeler gibi sonraki süreç adımlarını belirler. Ödeme bildiriminin alınmasına kadar geçen süre, ödeme yapan kuruluşun performansını ölçer. Nereden alınır? Bu olay, sistemin 835 dosyası gibi bir elektronik veri değişimi (EDI) dosyasını içe aktarmasıyla veya kullanıcının basılı bir Ödenek Açıklaması (EOB) belgesindeki verileri elle girmesiyle kaydedilir. Kaydedin Taleple ilişkili ödeme bildirimi dosyasının işlenme veya içe aktarılma zaman damgasını kullanın. Olay türü explicit | |||
| Ret için yeniden çalışma başladı | Bir kullanıcı veya otomatik iş akışı, reddedilen bir talebi inceleyip çözme sürecini başlatmıştır. Bu etkinlik, ret kararına itiraz etmek ve olası geliri tahsil etmek için yürütülen iç sürecin başlangıcını işaret eder. | ||
| Neden önemli? Bu etkinlik, ret için yeniden çalışma döngüsünü başlatır. Ret ile yeniden çalışmanın başlaması arasındaki süreyi analiz etmek, ret yönetimi ekibinin yanıt hızını ölçmeye ve birikmiş işleri belirlemeye yardımcı olur. Nereden alınır? Bu bilgi, ret yönetimi modülündeki kullanıcı işlemlerinden, talep durumundaki bir değişiklikten veya reddedilen talebin bir kullanıcının iş kuyruğuna atanmasından elde edilebilir. Kaydedin Reddedilen talebin ilk kez açıldığı, atandığı veya durumunun 'Yeniden çalışılıyor' olarak değiştirildiği zaman damgasını kaydedin. Olay türü explicit | |||
| Tahsilat başladı | Hasta hesabının ödemesi gecikmiştir ve proaktif tahsilat çalışmaları başlatılır. Bu çalışmalar, otomatik hatırlatma mektuplarından hesabın kurum içi veya harici bir tahsilat uzmanına devredilmesine kadar değişebilir. | ||
| Neden önemli? Bu aşama, vadesi geçmiş alacakları tahsil etme çalışmalarının yoğunlaştırıldığını gösterir. Bu etkinliği izlemek, tahsilat stratejilerinin ve tahsilat kuruluşlarının performansını değerlendirmeye yardımcı olur. Nereden alınır? Bu bilgi genellikle hesabın finansal sınıfındaki veya durum kodundaki değişiklikten ya da hesabın belirli bir tahsilat iş kuyruğuna veya tahsilat kuruluşuna atanmasından elde edilir. Kaydedin Hesap durumunun ilk kez 'Tahsilat', 'Vadesi geçmiş' veya benzer bir duruma geçtiği zaman damgasını kullanarak bu olayı belirleyin. Olay türü inferred | |||
| Talep oluşturuldu | Sistem, tüm ücretleri, kodları ve demografik bilgileri standart bir biçimde bir araya getirerek resmî bir faturalama talebi oluşturmuştur. Bu, talebin ödeme yapan kuruluşa gönderilmesinden önceki hazırlık adımıdır. | ||
| Neden önemli? Bu aşamada faturalandırılabilir bir talep gönderilmeye hazırdır. Bu noktadan gönderime kadar geçen süreyi analiz etmek, faturalama sürecini yavaşlatan sistem veya toplu işlem gecikmelerini belirlemeye yardımcı olur. Nereden alınır? Bu, talepler tablosuna veya dosyasına kaydedilmesi gereken, sistem tarafından oluşturulmuş bir olaydır. Talep üstbilgisi için oluşturulma zaman damgası açıkça belirtilmelidir. Kaydedin Faturalama olayıyla ilişkili ana talep kaydının oluşturulma zaman damgasını kullanın. Olay türü explicit | |||
| Talep yeniden gönderildi | Ret veya geri çevirme sonrasında talep düzeltilmiş ve yeniden değerlendirilmek üzere ödeme yapan kuruluşa gönderilmiştir. Bu, ödeme almak için yapılan ikinci girişimdir ve ilk yeniden çalışma döngüsünü tamamlar. | ||
| Neden önemli? Bu etkinlik, ret çözüm sürecinin verimliliğini anlamak açısından önemlidir. Yeniden gönderimleri izlemek, yeniden çalışma çevrim sürelerini ve itirazların başarı oranını ölçmeye yardımcı olur. Nereden alınır? Bu işlem, ilk reddedilen taleple bağlantılı yeni bir talep gönderim olayı olarak kaydedilir. Düzeltme veya yeniden gönderim göstergesi bulunan gönderim kayıtlarını arayın. Kaydedin Daha önce gönderilmiş bir talep kimliğine atıfta bulunan veya yeniden gönderim işareti taşıyan bir talep gönderim işlemi belirleyin. Olay türü explicit | |||
| Ücretler kaydedildi | Hasta karşılaşması kapsamında ücretlendirilebilir tüm hizmetlerin, prosedürlerin ve malzemelerin resmî olarak kaydedilmesini ifade eder. Bu adım, klinik faaliyetleri faturalandırılabilir finansal işlemlere dönüştürür. | ||
| Neden önemli? Hizmetin sunulmasıyla ücretlerin kaydedilmesi arasındaki süreyi analiz etmek, gelirin kayda alınmasındaki olası gecikmeleri ortaya çıkarır. Bu adım, ücretlendirilebilir tüm hizmetlerin hesaba katılması ve gelir kaybının önlenmesi açısından önemlidir. Nereden alınır? Bu veriler, faturalama veya hasta muhasebesi sistemindeki ücret işlem tablolarında ya da finansal kayıtlarda bulunur. Ücretlendirilebilir her kalem için ilgili oluşturulma zaman damgası kaydedilmiş olmalıdır. Kaydedin Faturalama olayıyla bağlantılı ücret işlemi kayıtlarının oluşturulma tarihini kullanın. Olay türü explicit | |||
Veri çıkarma rehberleri
Veri çıkarma yöntemleri sisteme göre değişir. Ayrıntılı talimatlar için
Başlamaya hazır mısınız?
Verilerinizi dışa aktarmaya ilişkin ayrıntılı yönergeler için aşağıdaki sistemlere özel veri çıkarma rehberlerinden birini seçin. Başka bir sistem kullanıyorsanız bu genel şablonu başlangıç noktası olarak kullanabilirsiniz.
Gelir döngüsü yönetiminizi şimdi dönüştürün
İçgörüler edinin, retleri azaltın ve tüm sistemlerde nakit akışını hızlandırın.
Kredi kartı gerekmez • Dakikalar içinde başlayın