Gelir Döngüsü Yönetimi Data Template'iniz

Faaliyet Adı, 'Talep Ödeme Kuruluşuna Gönderildi' veya 'Ödeme Alındı' gibi gelir döngüsü sürecindeki bir adımı tanımlar. Bu nitelik, süreç haritasındaki düğümleri tanımladığı için süreç madenciliği için temeldir.\n\nFaaliyetlerin sırasını ve sıklığını analiz ederek, kuruluşlar gerçek süreç akışını görselleştirebilir, standart prosedürden sapmaları belirleyebilir ve yaygın yeniden işleme döngülerini saptayabilir. Bu analiz, süreç verimsizliklerini ve uyum sorunlarını anlamak için anahtardır.

Bu öznitelik, sürecin bireysel adımlarını tanımlar, süreç haritasının temelini oluşturur ve tüm akış tabanlı analizleri mümkün kılar.

Bu genellikle Optum360'ın operasyonel tablolarındaki event log'larından, durum değişikliği kayıtlarından veya belirli işlem kodlarından türetilir.

Faturalama Event'i, tek bir sağlanan hizmet veya ücret oluşturan teslim edilmiş ürünle ilgili tüm faaliyetleri birbirine bağlayan birincil case tanımlayıcısı olarak hizmet eder. Bu, her bir faturalandırılabilir kalem veya hizmet için gelir oluşturma ve tahsilat yaşam döngüsünün kapsamlı bir şekilde takip edilmesini sağlar.

Process Mining'de, Faturalama Event'ine göre süreci analiz etmek, kuruluşların hizmet sunumundan nihai ödeme veya hesap kapanışına kadar tüm uçtan uca yolculuğu görmesine olanak tanır. Bu görünüm, bottleneck'leri belirlemek, döngü sürelerini ölçmek ve farklı taleplerin veya faturaların nasıl işlendiğindeki varyasyonları anlamak için hayati öneme sahiptir.

Bu, ilgili tüm gelir döngüsü aktivitelerini birbirine bağlayan temel Case ID'sidir ve analiz için eksiksiz, uçtan uca bir süreç görünümü sağlar.

Bu, Optum360'ın çekirdek faturalama ve talep tablolarındaki kayıtları birbirine bağlayan birincil anahtardır. Belirli tablo ve alan adları için Optum360 dokümantasyonuna bakın.

Olay Zamanı, her faaliyetle ilişkili zaman damgası olup, gerçekleştiği kesin tarih ve saati işaret eder. Bu zamansal veri, her vaka için olayların kronolojik sırasını oluşturmak için esastır.\n\nAnalizde, Olay Zamanı, faaliyetler arasındaki döngü sürelerini hesaplamak, vaka süresini ölçmek ve önemli zamanın beklemeyle geçtiği darboğazları belirlemek için kullanılır. Zaman tabanlı herhangi bir süreç analizi ve performans ölçümünün omurgasıdır.

Bu timestamp, event'leri doğru sıralamak ve cycle time'lar ve bottleneck'ler gibi süre tabanlı tüm metrikleri hesaplamak için kritiktir.

Bu bilgi genellikle Optum360'ın database tablolarındaki her işlem veya durum değişikliği kaydının yanında saklanır.

Düzeltilmiş Tutar, ödeme yapanlarla yapılan sözleşmeler, faturalama düzeltmeleri veya diğer silmeler nedeniyle tahsil edilmesi beklenmeyen faturalandırılmış tutarın bir kısmını temsil eder. Bu, gelirin doğrudan bir azalmasıdır.

Bu öznitelik, "Gelir Düzeltme Etkisi" dashboard'u ve "Gelir Düzeltme Oranı" KPI'ı için kritik öneme sahiptir. Düzeltmeleri analiz etmek, ödeme yapan sözleşmelerin finansal etkisini belirlemeye ve faturalama doğruluğunu veya sözleşme müzakerelerini iyileştirerek gelir kaybını en aza indirme fırsatlarını bulmaya yardımcı olur.

Gelir sızıntısını doğrudan ölçer ve finansal performans KPI'larını hesaplamak ile karlılığı anlamak için kritik öneme sahiptir.

Bu bilgi, Optum360'ın finansal sistemindeki düzeltme işlem kayıtlarında bulunur.

Faturalama Departmanı özniteliği, gelir döngüsü operasyonları içinde bir faaliyetten sorumlu belirli ekibi veya fonksiyonel alanı tanımlar. Örneğin, farklı ekipler kodlama, talep gönderimi ve ret yönetimi ile ilgilenebilir.

Bu öznitelik, "Faturalama Departmanı Performans Kıyaslamaları" dashboard'u tarafından talep edildiği üzere performans kıyaslaması için çok önemlidir. Liderliğin farklı ekiplerin verimliliğini, hızını ve doğruluğunu karşılaştırmasına, en iyi uygulamaları belirlemesine ve performans açıklarını gidermek için kaynakları etkili bir şekilde tahsis etmesine olanak tanır.

Farklı faturalandırma ekipleri arasında performans karşılaştırması yapılmasını sağlar, yüksek performans gösteren grupları ve iyileştirme gereken alanları belirlemeye yardımcı olur.

Bu, görevi gerçekleştiren kullanıcıdan veya hesaptaki sahipliği gösteren bir alandan türetilebilir. Optum360 dokümantasyonuna bakın.

Faturalanan Tutar, sunulan hizmetler için herhangi bir ödeme, düzeltme veya silme öncesindeki brüt ücreti temsil eder. Faturalandırma olayı için alacak hesabının başlangıç değeridir.\n\nBu nitelik, süreç madenciliği içindeki finansal analiz için temeldir. Gelir Düzeltme Oranı gibi temel KPI'ları hesaplamak için kullanılır ve yüksek değerli taleplerin farklı şekilde işlenip işlenmediğini veya düşük değerli taleplere göre daha fazla gecikme yaşayıp yaşamadığını görmek için vakaları değere göre segmentlere ayırmaya olanak tanır.

Her vaka için finansal bağlam sağlar, değer tabanlı analiz ve kritik finansal KPI'ların hesaplanmasını mümkün kılar.

Bu, Optum360'ın finansal tablolarındaki her talep veya hasta hesabında standart bir alandır.

Hasta ID'si, sağlık sistemi içindeki her hastaya atanan benzersiz bir tanımlayıcıdır. Birden fazla faturalama event'ini tek bir hastaya bağlayarak hasta merkezli analize olanak tanır.

Hasta ID'sini kullanarak analistler, sık sık yeniden yatışlar veya talep reddi geçmişi gibi belirli hastalarla ilgili kalıpları inceleyebilir. Ayrıca, süreci hasta demografisi veya geçmişine göre bölümlendirmeye olanak tanır, bu da hasta finansal deneyimini iyileştirmek için önemli içgörüler ortaya çıkarabilir.

Hasta odaklı analiz yapılmasına olanak tanır, uçtan uca finansal yolculuğu anlamaya ve belirli hasta popülasyonları için kalıpları belirlemeye yardımcı olur.

Bu tanımlayıcı, Optum360 içindeki hasta ana data'sı ve işlem tablolarında temel bir alandır. Detaylar için Optum360 dokümantasyonuna bakın.

Ödeyici ID'si, talebi ödemekten sorumlu belirli sigorta şirketini, Medicare veya Medicaid gibi devlet programını veya diğer kuruluşu tanımlar. Her ödeyicinin genellikle kendi kuralları, gönderim gereksinimleri ve ödeme davranışları vardır.

Ödeyici ID'sine göre süreci analiz etmek RCM için kritik öneme sahiptir. Hangi ödeyicilerin en uzun ödeme döngülerine, en yüksek ret oranlarına veya en karmaşık itiraz süreçlerine sahip olduğunu belirlemeye yardımcı olur. Bu içgörü, faturalama departmanlarının farklı ödeyiciler için tahsilat hızını artırmak ve idari yükü azaltmak üzere stratejilerini uyarlamasına olanak tanır.

Süreci ödeme kuruluşuna göre segmentlere ayırmak, hangi ödeme kuruluşlarının gecikmelere veya retlere neden olduğunu belirlemek için esastır; bu da ödeme kuruluşu yönetiminde hedeflenmiş iyileştirmeler sağlar.

Bu bilgi, Optum360 içindeki her talep kaydında saklanır. Ödeyiciyle ilgili tablo ve alan adları için Optum360 dokümantasyonuna bakın.

Bir ödeyici bir talebi reddettiğinde, "Service Not Covered" veya "Duplicate Claim" gibi sorunu açıklayan bir Denial Reason Code sağlar. Bu kodlar, gelir gecikmelerinin ve rework ihtiyacının temel nedenlerini anlamak için hayati öneme sahiptir.

Bu kodları analiz etmek, denial management team'inin çalışmalarını önceliklendirmesine, trendleri belirlemesine ve corrective actions uygulamasına olanak tanır. Örneğin, "Missing Information" nedeniyle yüksek sıklıkta denial'lar, claims creation process'inde bir soruna işaret edebilir. Bu analiz, denial rate'ini azaltmak ve cash flow'u hızlandırmak için merkezi bir rol oynar.

Talep retlerinin temel nedenini sağlar, gelecekteki retleri önlemek ve maliyetli yeniden işleme miktarını azaltmak için hedeflenmiş müdahaleler sağlar.

Bu kod, ödeyicilerden alınan Elektronik Ödeme Bildirimi (ERA) dosyalarında yer alır ve Optum360'ın talep yönetimi modülünde saklanır.

Bitiş Zamanı, bir aktivitenin tamamlandığını işaret eder. Başlangıç Zamanı bir event'in ne zaman meydana geldiğini gösterirken, Bitiş Zamanı "Ret İşlemi Başlatıldı" gibi belirli bir işlem süresi olan aktivitelerin süresini hesaplamak için gereklidir.

Süreç analizinde, aktiviteler için Başlangıç Zamanı ve Bitiş Zamanı'nı karşılaştırmak, işlem süresinin hesaplanmasına olanak tanır. Bu, aktif çalışma süresi (işlem süresi) ile boşta kalma süresi (aktiviteler arası bekleme süresi) arasında ayrım yapmaya yardımcı olarak süreç verimliliğine daha ayrıntılı bir bakış sunar.

Kesin faaliyet işlem sürelerinin hesaplanmasını sağlar, süreçteki aktif çalışma süresini boş bekleme süresinden ayırmaya yardımcı olur.

Bazı faaliyetler için bu, kaynak sistemde ayrı bir zaman damgası alanı olabilir. Diğerleri için ise sonraki faaliyetin başlangıç zamanından çıkarılması gerekebilir.

Hesap Durumu, bir faturalandırma olayının genel süreçte nerede olduğuna dair bir anlık görüntü sunar; örneğin, 'Ödeme Kuruluşu Beklemede', 'Tamamen Ödendi' veya 'Tahsilatta'. Bu nitelik, gerçekleştirilen faaliyetlere bağlam sağlar.\n\nBu, sürecin belirli bölümlerine odaklanmak için vakaları filtrelemek ve bölümlere ayırmak için kullanışlıdır. Örneğin, şu anda 'Tahsilatta' olan tüm hesapları analiz etmek, sürecin bu belirli, maliyetli kısmının itici güçlerini ve hacmini anlamaya yardımcı olabilir, böylece 'Tahsilat Faaliyeti Hacmi ve Etkenleri' Dashboard'unu destekler.

Bir vakanın mevcut durumuna dair üst düzey bağlam sağlar, tahsilattaki vakalar gibi belirli vaka popülasyonlarının filtrelenmesine ve analiz edilmesine olanak tanır.

Bu genellikle Optum360'daki ana hasta hesabı veya talep kaydında bir özet alandır.

Hizmet Kodu, hastaya sağlanan prosedürü veya hizmeti kesin olarak tanımlayan standart bir tıbbi koddur. Bu kodlar faturalama için gereklidir ve geri ödemenin birincil belirleyicisidir.

Hizmet Koduna göre süreci analiz etmek, belirli prosedürlerin retlere daha yatkın olduğunu, daha fazla dokümantasyon gerektirdiğini veya daha uzun ödeme döngülerine sahip olduğunu ortaya çıkarabilir. Bu, süreç zorluklarının daha ayrıntılı anlaşılmasını sağlar ve belirli hizmet türleri için kodlama ve faturalama politikalarını bilgilendirebilir.

Tıbbi hizmet türüne göre analiz yapılmasına olanak tanır; bu da belirli prosedürlere özgü ret veya ödeme gecikmelerindeki kalıpları ortaya çıkarabilir.

Bu kod, Optum360'daki ücret girişi ve talep detay kayıtlarının temel bir parçasıdır.

Bu öznitelik, hizmeti sunmaktan sorumlu belirli sağlayıcıyı, örneğin bir doktoru, terapisti veya hastane departmanını tanımlar. Farklı sağlayıcıların, gelir döngüsünü etkileyen farklı faturalama kalıpları veya dokümantasyon alışkanlıkları olabilir.

Hizmet Sağlayıcısına göre analiz yapmak, ücret yakalama, kodlama doğruluğu veya bakım noktasında ortaya çıkan dokümantasyon kalitesi ile ilgili sorunları belirlemeye yardımcı olabilir. Sağlayıcı eğitimi veya süreç iyileştirmesi için fırsatları vurgulayarak, baştan itibaren doğru taleplerin oluşturulmasını sağlayabilir.

Faturalandırma sorunlarını kaynağına kadar takip etmeye yardımcı olur, klinik personele ücret tahsilatı ve dokümantasyonu iyileştirmek için hedeflenmiş geri bildirim ve eğitim sağlar.

Bu bilgi, Optum360'daki ücret veya talep kaydının önemli bir parçasıdır ve genellikle sağlayıcı ana data'sı ile ilişkilidir.

İşlem Süresi, bireysel bir faaliyetin süresini ölçer, 'dokunma süresi' veya gerçekleştirilen aktif işi temsil eder. Bu genellikle bir faaliyetin Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark olarak hesaplanır.\n\nBu hesaplanmış metrik, bir görev üzerinde aktif olarak harcanan süre ile bir sonraki adımı beklemekle geçen süre arasında ayrım yapmak için çok önemlidir. Darboğaz analizinde, işlem sürelerini anlamak, bir gecikmenin uzun bir görevden mi yoksa uzun bir kuyruktan mı kaynaklandığını belirlemeye yardımcı olur ve daha etkili süreç iyileştirmelerine yol açar.

Faaliyetler için aktif 'dokunma süresini' ölçer, darboğaz analizinde katma değerli işi israf olan bekleme süresinden ayırmaya yardımcı olur.

Bu, belirli bir aktivite kaydı için "EndTime"den "EventTime" (StartTime) çıkarılarak hesaplanır.

Bu öznitelik, belirli bir event için verilerin çıkarıldığı kaynak sistemi tanımlar. Karmaşık bir BT ortamında, RCM data'sı ana Optum360 platformundan, arayüzlenmiş bir Elektronik Sağlık Kaydı (EHR) sisteminden, bir clearinghouse'dan veya bir hasta portalından gelebilir.

Kaynak sistemi anlamak, data doğrulama, entegrasyon sorunlarını giderme ve farklı sistem davranışları veya data giriş uygulamalarından kaynaklanabilecek süreç varyasyonlarını analiz etme açısından faydalıdır.

Verinin kaynağını tanımlar; bu da veri yönetimi, kalite değerlendirmesi ve farklı sistemler arasındaki süreç varyasyonlarını anlamak için kritik öneme sahiptir.

Bu, data çıkarma sırasında ayarlanan statik bir değer veya kaynak tablolarda data'nın kökenini gösteren bir alan olabilir.

Kullanıcı özniteliği, belirli bir aktiviteyi yürütmekten sorumlu belirli kişiyi, ekibi veya otomatik botu tanımlar. Bu, bireysel veya grup düzeyinde performans analizine olanak tanır.

Hangi kullanıcının veya ekibin bir eylemi gerçekleştirdiğini anlamak, üretkenliği, kaliteyi ve standart prosedürlere bağlılığı değerlendirmek için değerlidir. Eğitim ihtiyaçlarını belirlemeye veya yüksek performans gösteren bireyleri ve ekipleri tanımaya yardımcı olabilir. Ayrıca manuel olarak yapılan görevler ile otomasyon tarafından yönetilen görevler arasında ayrım yapmaya da yardımcı olur.

Süreç adımları için sorumluluk atar ve birey veya ekip tarafından performans analizini sağlar; bu da kaynak yönetimi ve eğitim için anahtardır.

Kullanıcı ID'leri genellikle Optum360'daki kayıtlar için audit log'larında veya transaction history'de yakalanır.

Ödenen Tutar, belirli bir faturalama event'i için hesaba kaydedilen tüm ödemelerin kümülatif toplamıdır. Bu, fiilen tahsil edilen nakdi temsil eder ve gelir döngüsünün başarısının birincil ölçüsüdür.

Süreç analizinde, ödenen tutarı takip etmek nakit akışını ve genel finansal performansı anlamak için hayati öneme sahiptir. Ödeme hızını analiz etmek ve faturalandırılan tutarları tahsil edilen tutarlarla karşılaştırmak için kullanılabilir, eksik ödemeler veya tahsil edilemeyen borçlarla ilgili sorunları vurgular.

Gerçekleşen nakit tahsilatını temsil eder; bu da GDY süreci için anahtar bir sonuç metriği ve nakit akışı analizi için esastır.

Bu değer genellikle Optum360'daki payment transaction tablolarında saklanır veya account level'da özetlenir.

Bu öznitelik, verilerin kaynak sistemden en son ne zaman çıkarılıp Process Mining aracına yüklendiği tarihi ve saati kaydeder. Analiz edilen verinin güncelliği hakkında bağlam sağlar.

Bu, analistlerin ve iş kullanıcılarının en güncel bilgileri görüp görmediklerini anlamaları için önemlidir. Data latency'si hakkındaki beklentileri yönetmeye yardımcı olur ve herhangi bir analiz projesi için anahtar bir metadata parçasıdır.

Veri güncelliği hakkında kritik bağlam sağlar, kullanıcıların analizin ne kadar güncel olduğunu anlamalarını sağlar.

Bu timestamp genellikle data extraction, transformation, and loading (ETL) süreci tarafından oluşturulur ve saklanır.

Vaka Süresi, tek bir Faturalandırma Olayı için ilk olaydan son olaya kadar geçen toplam süreyi ölçer. Bu, genel süreç verimliliğini değerlendirmek için anahtar bir üst düzey KPI'dır.\n\nBu metrik, 'GDY Uçtan Uca Döngü Süresi Genel Bakışı' Dashboard'unu ve 'Ortalama GDY Döngü Süresi' KPI'ını doğrudan destekler. Bunu zamanla izlemek, yönetimin iyileştirme girişimlerinin tüm gelir döngüsü üzerindeki etkisini görmesini sağlar.

Sürecin uçtan uca döngü süresini temsil eder; genel süreç hızını ve verimliliğini ölçmek için kritik bir KPI'dır.

Bu, her benzersiz "BillingEvent" case ID'si için ilk event'in timestamp'ından son event'in timestamp'ı çıkarılarak hesaplanır.

Yeniden işleme, 'Ret Yeniden İşlemesi Başlatıldı' veya 'İtiraz Gönderildi' gibi katma değersiz yeniden işleme olarak kabul edilen faaliyetleri tanımlayan bir boolean bayraktır. Bu faaliyetler genellikle süreç ideal 'mutlu yolundan' saptığında meydana gelir.\n\nBu nitelik, süreçteki yeniden işleme miktarını nicelendirmeye yardımcı olur; bu da verimsizliğin ve maliyetin doğrudan bir göstergesidir. 'Faturalandırma Hatası Yeniden İşleme Oranı' KPI'ını hesaplamak için kullanılır ve bu verimsiz döngüleri filtrelemeyi ve görselleştirmeyi kolaylaştırarak 'Darboğaz Tanımlama ve Yeniden İşleme Döngüleri' Dashboard'unu destekler.

Yeniden işleme temsil eden faaliyetleri işaretleyerek süreç verimsizliğini nicelendirmeye yardımcı olur, böylece israfı ölçmeyi ve hedeflemeyi kolaylaştırır.

Bu, genellikle Process Mining aracı içindeki iş mantığı kullanılarak türetilir. Örneğin, "Denial Received" event'ini takip eden herhangi bir aktivite, rework olarak işaretlenebilir.