Gelir Döngüsü Yönetimi Veri Templateiniz
Gelir Döngüsü Yönetimi Veri Templateiniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Oracle Health Gelir Döngüsü için çıkarım rehberliği
Gelir Döngüsü Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet Adı ActivityName | Gelir döngüsü süreci içinde meydana gelen belirli adım veya `event`'in adı. | ||
| Açıklama Bu öznitelik, bir faturalandırma etkinliğinin yaşam döngüsü boyunca gerçekleştirilen her bir aktivitenin adını kaydeder. 'Ücretler Girildi', 'Talep Gönderildi' ve 'Ödeme Kaydedildi' gibi işlemler buna örnektir. Bu aktiviteler, ortaya çıkarılan süreç haritasının düğüm noktalarını oluşturur. Aktivitelerin sırasını ve sıklığını analiz etmek Process Mining'in özüdür. Bu öznitelik, en yaygın süreç yollarını belirlemeye, standart prosedürden sapmaları keşfetmeye ve gelir döngüsünün operasyonel akışını anlamaya yardımcı olur. Neden önemli Süreçteki adımları tanımlar, süreç haritasının görselleştirilmesine ve workflow kalıplarının analizine olanak tanır. Nereden alınır Tipik olarak Örnekler Talep OluşturulduHavale AlındıRet İtiraz EdildiHesap Kapatıldı | |||
| Faturalama Event'i BillingEvent | Bir ücret oluşturan tek bir hizmet veya ürün teslimatı için benzersiz tanımlayıcı, gelir döngüsü süreci için `case` tanımlayıcısı görevi görür. | ||
| Açıklama Faturalandırma Olayı, ayrı bir faturalandırılabilir kalem için tahsilat işleminden hesap kapanışına kadar tüm aktiviteleri birbirine bağlayan birincil
Neden önemli Bu, faturalandırılabilir bir hizmetin tüm yaşam döngüsünü izlemek için temel anahtardır ve tüm Nereden alınır Bu tanımlayıcı, Oracle Health Gelir Döngüsü içindeki temel faturalandırma veya tahsilat işlem tablolarında bulunan benzersiz bir anahtar olmalıdır. Ücret Örnekler BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Olay Zaman Damgası EventTimestamp | Bir aktivitenin sisteme kaydedildiği kesin tarih ve saat. | ||
| Açıklama Bu öznitelik, her bir aktivitenin gerçekleştiği anı işaretleyen timestamp bilgisini sağlar. Belirli bir faturalandırma etkinliği için gelir döngüsü içindeki olayların zamanlamasını ve sırasını anlamak açısından temeldir. Analizlerde Event Timestamp, aktiviteleri kronolojik sıraya koymak, adımlar arasındaki süreleri hesaplamak ve bottleneck analizi yapmak için kullanılır. 'Talep Gönderildi' ile 'Ödeme Alındı' arasındaki gecikmelerin belirlenmesi gibi, zaman tabanlı tüm Process Mining metriklerinin temelini oluşturur. Neden önemli Bu timestamp, etkinliklerin sıralanması, döngü süreleri gibi tüm performans metriklerinin hesaplanması ve süreçteki darboğazların belirlenmesi için kritiktir. Nereden alınır Oracle Health Gelir Döngüsü'ndeki her transaction veya event log table'ında, kaydın ne zaman oluşturulduğunu veya event'in ne zaman gerçekleştiğini gösteren bir timestamp sütunu bulunmalıdır. Örnekler 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Düzeltme Tutarı AdjustmentAmount | Hesap bakiyesinde yapılan herhangi bir düzeltmenin parasal değeri. | ||
| Açıklama Bu 'Hesap Düzeltme Etkisi' Neden önemli İptaller veya düzeltmeler nedeniyle gelir kaybını nicelleştirir, finansal aşınmanın temel nedenlerini belirlemeye ve ele almaya yardımcı olur. Nereden alınır Bir hasta hesabına yapılan düzeltmeleri veya iptalleri kaydeden finansal işlem tablolarında bulunur. Örnekler -50.25-120.0025.00 | |||
| Fatura Departmanı BillingDepartment | Aktiviteden sorumlu departman veya fonksiyonel ekip. | ||
| Açıklama Bu öznitelik; 'Ücret Girişi', 'Kodlama' veya 'Tahsilat' gibi aktiviteyi gerçekleştiren departmanı belirtir. Süreç akışına kurumsal bir bağlam kazandırır. Süreci departman bazlı analiz etmek, ekipler arasındaki devirleri anlamak ve fonksiyonlar arası verimsizlikleri belirlemek için gereklidir. Aktivitelerin ve performans metriklerinin departman düzeyinde gruplandırılmasına olanak tanıyarak 'Faturalandırma Departmanı İş Yükü' dashboard ekranını destekler. Neden önemli Aktiviteleri organizasyonel birimlere atar, bu da departmanlar arası devirleri, iş yükünü ve ekip performansını analiz etmek için anahtardır. Nereden alınır Bu bilgi, Oracle Health'teki kullanıcı profili Örnekler Hasta ErişimiKodlamaFaturalandırmaTahsilatlar | |||
| Hasta Sınıfı PatientClass | Yatan veya Ayakta Hasta gibi hasta karşılaşmasının sınıflandırılması. | ||
| Açıklama Bu Farklı hasta sınıfları, ayrı süreç yollarını izler ve farklı Neden önemli Farklı karmaşıklıklara, zaman çizelgelerine ve faturalandırma gereksinimlerine sahip ayrı süreç akışlarını (örneğin, Yatan Hasta ile Ayakta Hasta) ayırır. Nereden alınır Bu, Oracle Health'te bir hasta karşılaşması veya kabul kaydıyla ilişkili standart bir alandır. Örnekler Yatan HastaAyakta TedaviAcilTekrarlayan | |||
| Kullanıcı UserPerformingAction | Aktiviteyi gerçekleştiren kişinin kullanıcı ID'si veya adı. | ||
| Açıklama Bu Analizde, bu Neden önemli Süreç aktivitelerini belirli kullanıcılara veya ekiplere bağlar, iş yükü analizi, performans karşılaştırması ve eğitim fırsatlarının belirlenmesini sağlar. Nereden alınır Kullanıcı Kimliği alanları (örneğin, 'CREATED_BY', 'USER_ID') tipik olarak Oracle Health modüllerindeki işlem tablolarında bulunur. Örnekler j.doeasmithBillingBot_AUTOk.williams | |||
| Ödenmemiş Bakiye OutstandingBalance | Belirli bir zamanda faturalandırma `event`'i için kalan ödenmemiş bakiye. | ||
| Açıklama Bu öznitelik, tüm ödemeler ve düzeltmeler uygulandıktan sonra bir faturalandırma etkinliği için kalan güncel borç tutarını gösterir. O spesifik işlem için aktif alacakları temsil eder. Bu, 'Vadesi Geçmiş Bakiye Yaşlandırma' dashboard ekranı için kritik bir özniteliktir. Bu değerin zaman içindeki değişimini analiz etmek, nakit akış hızını izlemeye, tahsilat çabalarının etkinliğini değerlendirmeye ve Günlük Satış Alacakları (DSO) gibi temel finansal KPI'ları hesaplamaya yardımcı olur. Neden önemli Her bir case için güncel alacakları takip eder; bu da nakit akışını yönetmek ve tahsilatın etkinliğini analiz etmek için esastır. Nereden alınır Bu değer, belirli bir faturalandırma Örnekler 75.000.00550.80 | |||
| Ödeyen Adı PayerName | Ödemeden sorumlu sigorta şirketi veya üçüncü taraf ödeyenin adı. | ||
| Açıklama Bu Süreci ödeyiciye göre analiz etmek, ödeme sürelerinde, ret oranlarında ve itiraz başarı oranlarında önemli farklılıkları ortaya çıkarabilir. Gecikmelere veya gelir kaybına neden olan sorunlu ödeyicileri belirlemeye yardımcı olur ve ödeyici sözleşmelerini ve ilişkilerini etkili bir şekilde yönetmek için gereklidir. Neden önemli Sürecin ödeme yapana göre segmentasyonuna olanak tanır, bu da finansal performans için kritik olan farklı davranışları, ret oranlarını ve ödeme hızlarını ortaya çıkarır. Nereden alınır Bu bilgi, Oracle Health Gelir Döngüsü içindeki hastanın faturalandırma veya sigorta kayıtlarında saklanır. Örnekler AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Ret Neden Kodu DenialReasonCode | Ödeme yapan tarafından bir talebin reddedilme nedenini gösteren standartlaştırılmış bir kod. | ||
| Açıklama Bir ödeyici bir talebi reddettiğinde, ret nedenini açıklayan bir neden kodu sağlar; örneğin 'Kapsam Dışı Hizmet' veya 'Çift Talep'. Bu Ret nedenlerini analiz etmek, gelir döngüsünü iyileştirmek için temeldir. Kuruluşun, kodlama veya hasta uygunluğu gibi yaygın kalıpları belirlemesine ve gelecekteki retleri önlemek için düzeltici eylemler uygulamasına olanak tanır. Bu, doğrudan temiz talep oranını etkiler ve yeniden çalışma maliyetini azaltır. Neden önemli Talep retlerinin temel nedenini sağlar, temiz talep oranını artırmak ve gelir tahsilatını hızlandırmak için hedeflenen iyileştirmeleri mümkün kılar. Nereden alınır Bu bilgi, ödeyiciden elektronik havale bildiriminde (ANSI 835 dosyası) alınır ve Oracle Health'teki talep veya havale tablolarında saklanmalıdır. Örnekler CO-16: Talep/hizmet, hüküm için gerekli bilgiden yoksundur.PR-96: Kapsanmayan ücret(ler).CO-18: Yinelenen talep/hizmet. | |||
| Claim ID ClaimId | Bir ödeyene sunulan sigorta talebi için benzersiz tanımlayıcı. | ||
| Açıklama Bu Talep Kimliğini kullanmak, belirli bir gönderimi bir ödeyiciye kadar izlemeye ve bunu doğrudan ödeme veya ret gibi yanıtla bağlamaya olanak tanır. Geniş gelir döngüsü süreci içinde daha ayrıntılı bir izleme seviyesi sağlar. Neden önemli Bir talebin ödeme yapan ile olan yolculuğunu izlemek için belirli bir identifier sağlar, bu da genel faturalama event'inden daha ayrıntılıdır. Nereden alınır Bu kimlik, bir talep oluşturulduğunda Oracle Health tarafından oluşturulur ve birincil talep tablosunda saklanır. Örnekler CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Hasta ID PatientId | Faturalandırma `event`'iyle ilişkili hasta için benzersiz tanımlayıcı. | ||
| Açıklama Bu öznitelik, hizmet alan hastanın benzersiz kimlik numarasıdır ve genellikle Tıbbi Kayıt Numarası (MRN) olarak bilinir. Finansal işlemi belirli bir kişiyle ilişkilendirir. Sürecin case ID'si olmasa da Hasta Kimliği, tek bir hastaya ait tüm faturalandırma etkinliklerini birleştirerek hastanın tüm finansal yolculuğunu anlamak için kullanışlıdır. Ayrıca hasta ana verileriyle birleştirildiğinde, demografik özelliklere veya geçmişe dayalı segmentasyon yapılmasına olanak tanır. Neden önemli Finansal event'leri belirli bir hastaya bağlar, hasta odaklı analiz ve tüm faturalama aktivitelerinin birleştirilmesine olanak tanır. Nereden alınır Bu tanımlayıcı, hasta ana kaydının temel bir öğesidir ve ücretler, talepler ve ödemeler gibi ilgili tüm işlem tablolarında bulunacaktır. Örnekler MRN-1002345MRN-1002346MRN-1002347 | |||
| İşlem Süresi ProcessingTime | Bir faaliyet üzerinde aktif olarak çalışılan süre. | ||
| Açıklama Bu öznitelik, bir etkinliğin aktif işlem süresini ölçer ve başlangıç ile bitiş zaman damgaları arasındaki fark olarak hesaplanır. Bir görev üzerinde fiilen çalışılan süre ile bir sonraki adımın beklendiği sürenin birbirinden ayrılmasına yardımcı olur. Performans analizi için kritik bir metrik olan bu değer, görevi gerçekleştiren kaynağın verimliliğini sistemsel gecikmelerden ayırır. Bir talebin kodlanması veya bir ödemenin girilmesinin, iş kuyruğunda bekleme süresinden bağımsız olarak ne kadar sürdüğünü anlamanızı sağlar. Neden önemli Bir aktivite için gerçek work duration'ını ölçer, idle veya wait time'dan ayırarak resource efficiency'sinin daha net bir görünümünü sağlar. Nereden alınır Bu, Örnekler 300120045 | |||
| Kaynak Sistem SourceSystem | Event verisinin çıkarıldığı sistem. | ||
| Açıklama Bu öznitelik, verinin hangi kaynak uygulama veya modülden geldiğini belirtir. Bu süreçte genellikle 'Oracle Health Revenue Cycle' olarak görünür, ancak veriler birden fazla kaynaktan geliyorsa sistem içindeki farklı modülleri de gösterebilir. Bu bilgi, veri yönetişimi ve sorun giderme süreçleri için değerlidir. Veri kaynağının doğrulanmasına yardımcı olur ve tek bir uçtan uca sürece birden fazla sistemin dahil olduğu ortamlarda büyük önem taşır. Neden önemli Data origin hakkında bağlam sağlar, bu da data validation, governance ve sistem bağımlı olabilecek süreç varyasyonlarını anlamak için kritik öneme sahiptir. Nereden alınır Bu, genellikle veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında veri setinin kaynağını etiketlemek için eklenen statik bir değerdir. Örnekler OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Olay Bitiş Zamanı EventEndTime | Bir aktivitenin tamamlandığını işaretleyen `timestamp`, eğer mevcutsa. | ||
| Açıklama StartTime bir aktivitenin başlangıcını, EventEndTime ise bitişini belirtir. Çoğu olay anlık gerçekleştiği için her aktivitenin net bir bitiş zamanı olmayabilir. Ancak, işlenmesi zaman alabilen 'Denial Appealed' gibi belirli bir süresi olan aktiviteler için bu alan çok kullanışlıdır. Bu öznitelik, münferit aktivitelerin işlem süresinin daha hassas hesaplanmasına olanak tanır. Bekleme süresi ile işlem süresinin ayırt edilmesine yardımcı olur. Neden önemli Bir aktivitenin tamamlanmasının ne kadar sürdüğünü doğrudan hesaplamayı sağlar, işlem süresini bekleme süresinden ayırır. Nereden alınır Oracle Health Gelir Döngüsü'ndeki bazı işlem tabloları, belirli, uzun süreli görevler için hem başlangıç hem de bitiş zaman damgası içerebilir. Örnekler 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Otomatikleştirildi mi? IsAutomated | Faaliyetin otomatik bir sistem tarafından mı yoksa bir insan kullanıcısı tarafından mı gerçekleştirildiğini gösteren bir işaret. | ||
| Açıklama Bu boolean Bu Neden önemli İnsan ve sistem odaklı aktiviteler arasında ayrım yapar, bu da otomasyon etkinliğini analiz etmek ve yeni otomasyon fırsatlarını belirlemek için kritiktir. Nereden alınır Bu, tipik olarak Örnekler truefalse | |||
| 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, veri setinin en son ne zaman güncellendiğini gösterir. Analiz edilen verilerin güncelliği hakkında bilgi verir; bu da Process Mining analizinden elde edilen içgörülerin zamanlamasını anlamak açısından önemlidir. Kullanıcılar, en güncel süreç bilgilerini görüntülediklerinden emin olmak için bu özniteliği kontrol edebilirler. Verilerin güncelliği konusundaki beklentilerin yönetilmesine yardımcı olur ve veri yönetişimi ile kalite güvencesinin temel bir bileşenidir. Neden önemli Data'ların güncelliğini gösterir, analiz ve kararların up-to-date bilgilere dayanmasını sağlar. Nereden alınır Bu, verilerin process mining platformuna yüklendiği ETL süreci sırasında genellikle otomatik olarak oluşturulan ve doldurulan bir meta veri alanıdır. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Ücret Tutarı ChargeAmount | Faturalanan hizmet veya ürünün brüt parasal değeri. | ||
| Açıklama Bu öznitelik, herhangi bir düzeltme, sözleşmeli indirim veya ödeme uygulanmadan önce bir hizmet için talep edilen ilk, indirimsiz tutarı temsil eder. Faturalandırma etkinliğinin başlangıçtaki finansal değeridir. Ücret tutarının takip edilmesi, sunulan hizmetlerin toplam değerinin hesaplanması ve sonradan yapılan düzeltmelerin veya silinen borçların finansal etkisinin anlaşılması gibi analizler için kritiktir. Gelir gerçekleşmesini ölçmek için bir temel teşkil eder. Neden önemli Bir case'in başlangıç finansal değerini belirler, bu da sonraki tüm finansal analiz ve etki değerlendirmesi için temeldir. Nereden alınır Oracle Health'teki ücret detayı veya ücret transaction tablolarında bulunur. Örnekler 150.001250.7585.50 | |||
| Uyuşmazlık Nedeni DisputeReason | Müşteri veya hastanın bir faturaya veya ücrete itiraz etmek için belirttiği neden. | ||
| Açıklama Bu Bu bilgi, 'Fatura İtiraz Çözüm Metrikleri' Neden önemli Faturalara neden itiraz edildiğini açıklar, faturalama doğruluğu veya netliği ile ilgili düzeltilmesi gereken sorunlara doğrudan içgörü sağlar. Nereden alınır Bu, büyük olasılıkla Oracle Health'teki bir Örnekler Yanlış Hizmet FaturalandırıldıYinelenen ÜcretSigorta Yanlış FaturalandırıldıHizmet Verilmedi | |||
| Yeniden İşleme mi? IsRework | Yeniden işleme veya tekrarlanan çabayı temsil eden aktiviteleri tanımlayan bir işaret. | ||
| Açıklama Bu hesaplanmış Yeniden çalışmayı belirlemek ve nicelleştirmek, Neden önemli Yeniden işleme döngülerinin sıklığını ve etkisini nicelleştirmeye yardımcı olur, süreç verimsizliklerini ve düşük kalite maliyetini vurgular. Nereden alınır Bu, türetilmiş bir Örnekler truefalse | |||
Gelir Döngüsü Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hasta Vakası Oluşturuldu | Belirli bir ziyaret veya hizmet için bir hasta hesabının oluşturulmasını işaretler. Bu genellikle kayıt sistemi veya bir Admit/Discharge/Transfer (ADT) feed'i tarafından tetiklenen açık bir event'tir. | ||
| Neden önemli Belirli bir faturalama event'i için tüm gelir döngüsünün başlangıç noktası olarak hizmet eder, toplam süreç süresinin ve kayıt doğruluğunun analizini sağlar. Nereden alınır Hasta Kayıt veya ADT modülü günlüklerinden alınmıştır. Karşılaşma oluşturma olaylarını veya karşılaşma ya da finansal numarayla ilişkili en erken zaman damgasını arayın. Yakala Hasta kaydı veya kabulü üzerine kaydedilen event. Event tipi explicit | |||
| Hesap Kapatıldı | Hesap bakiyesinin sıfır olduğunu ve başka bir aktivite beklenmediğini gösteren son aktivite. Bu genellikle hesap bakiyesi sıfıra ulaştığında çıkarılır. | ||
| Neden önemli Gelir döngüsünün başarılı bir şekilde tamamlanmasını işaretler. Bu duruma ulaşma süresi, genel süreç verimliliğinin anahtar bir ölçüsüdür. Nereden alınır Bu genellikle, hesabın ödenmemiş bakiyesinin tüm ödemeler ve düzeltmelerden sonra ilk kez sıfır olduğunu ve sıfır kaldığını belirleyerek çıkarılır. Yakala Tüm ücretler ve ödemeler kaydedildikten sonra hesap bakiyesi ilk kez sıfıra eşit olduğunda hesaplanır. Event tipi calculated | |||
| Ödeme Kaydedildi | Ödeme yapan tarafından alınan ödemenin, hastanın hesabındaki ilgili ücretlere uygulanmasını temsil eder. Bu, bir kullanıcı veya otomatik bir süreç tarafından kaydedilen bir finansal işlemdir. | ||
| Neden önemli Ödeme kaydetme verimliliği, alacak hesaplarının doğruluğunu etkiler. Buradaki gecikmeler finansal tabloyu bozabilir ve ikincil faturalandırmayı geciktirebilir. Nereden alınır Ödeme işlem tablolarında bulunur. Her ödeme kaydının benzersiz bir işlem ID'si ve ilişkili bir timestamp'i olacaktır. Yakala Ödeme hesaba uygulandığında bir finansal işlem kaydedilir. Event tipi explicit | |||
| Talep Ödeme Yapana Gönderildi | Oluşturulan talebin sigorta şirketine veya ödeme yapana elektronik veya kağıt olarak gönderilmesini temsil eder. Sistem, bu iletimin tarihini ve saatini log'lamalıdır. | ||
| Neden önemli Bu aktivite, ödeme döngüsünü başlatır. Gönderimden ödemeye kadar geçen süreyi analiz etmek, ödeyici performansını ve Günlük Satışlar Bekleyen (DSO) durumunu anlamanın anahtarıdır. Nereden alınır İletim olaylarını kaydeden talepler yönetimi modülünden alınmıştır. Talep geçmişinde bir gönderim zaman damgası veya 'Gönderildi' durum değişikliği arayın. Yakala Talebin clearinghouse aracılığıyla başarıyla iletildiğinde kaydedilen event. Event tipi explicit | |||
| Talep Oluşturuldu | Bireysel ücretlerin, UB-04 veya CMS-1500 gibi resmi bir faturalama talebi haline getirildiği noktayı işaretler. Bu, ilk faturayı oluşturan sistem tarafından üretilen bir event'tir. | ||
| Neden önemli Bu, bir ödeyiciye faturalandırmaya hazır olunduğunu gösteren önemli bir dönüm noktasıdır. Dahili tahsilat-fatura gecikmesini ölçmek için son noktadır. Nereden alınır Talep oluşturma log'larında veya tablolarında kaydedilmiş açık bir event. Vaka ile ilişkili birincil talep kaydının oluşturulma timestamp'ini arayın. Yakala Talep kaydının oluşturulması üzerine kaydedilen event. Event tipi explicit | |||
| Düzeltilmiş Talep Gönderildi | Düzeltilmiş veya yeniden gözden geçirilmiş bir talebin ödeme yapana gönderilmesini temsil eder, genellikle bir ret veya daha fazla bilgi talebini takiben. Bu, bir correction indicator ile yeni bir talep gönderimi ile tanımlanır. | ||
| Neden önemli Bu aktivite, ret yönetimi yeniden çalışma döngüsünün önemli bir parçasıdır. Yüksek sıklık, başlangıçtaki talep doğruluğunda sorunlar olduğunu gösterir. Nereden alınır Talep gönderim log'larından yakalanır. Mevcut bir vaka için yeni bir gönderim arayın, genellikle bir yeniden gönderim kodu veya daha yüksek bir iterasyon numarası ile işaretlenir. Yakala Bir talep resubmission'ı için kaydedilen event, genellikle belirli bir talep frekans tipi kodu ile tanımlanabilir. Event tipi explicit | |||
| Hasta Beyanı Gönderildi | Kalan hasta sorumluluğu için bir faturanın oluşturulup hastaya gönderildiği event'i işaretler. Bu, hasta faturalama module'ü tarafından kaydedilen açık bir eylemdir. | ||
| Neden önemli Bu, gelir döngüsünün hasta ödeme kısmını başlatır. Bunu izlemek, hasta tahsilatlarının etkinliğini analiz etmeye yardımcı olur. Nereden alınır Hasta faturalandırma veya yazışma kayıtlarından alınmıştır. Sistem, her beyannamenin oluşturulduğu veya gönderildiği tarihi kaydetmelidir. Yakala Hasta beyanı oluşturulduğunda ve yazdırıldığında veya elektronik olarak gönderildiğinde kaydedilen event. Event tipi explicit | |||
| Havale Alındı | Ödeme yapan tarafından bir Electronic Remittance Advice (ERA) veya kağıt Explanation of Benefits (EOB) alındığını gösterir. Bu belge, hangi ücretlerin ödendiğini, reddedildiğini veya düzeltildiğini detaylandırır. | ||
| Neden önemli Bu, ödeyiciden gelen ilk yanıttır ve ödeme hızını anlamak ve ret eğilimlerini erken belirlemek için çok önemlidir. Nereden alınır Havale işleme module'ünde kaydedilir. Taleple bağlantılı, 835 transaction file gibi ERA dosyasının import veya creation timestamp'ini arayın. Yakala Ödeme yapanın havale dosyasının (örn. ANSI 835) import edilmesi ve işlenmesi üzerine kaydedilen event. Event tipi explicit | |||
| Hesap Düzenlendi | Hesap bakiyesine yapılan, sözleşmesel bir indirim, bir write-off veya bir discount gibi finansal bir düzeltmeyi temsil eder. Her düzeltme ayrı bir finansal işlemdir. | ||
| Neden önemli Düzeltmeler geliri doğrudan etkiler. Frekanslarını, türlerini ve miktarlarını analiz etmek, gelir kaybını ve faturalama hatalarını belirlemeye yardımcı olur. Nereden alınır Finansal işlem tablolarında bulunur. Her düzeltme, belirli bir işlem kodu ve timestamp ile ayrı bir satır öğesi olarak kaydedilir. Yakala Belirli bir düzeltme koduyla bir finansal işlem kaydedilir. Event tipi explicit | |||
| Kodlanmış Ücretler | Medikal coders'ların yakalanan ücretlere CPT veya ICD-10 gibi standartlaştırılmış code'lar atadığı süreci temsil eder. Bu genellikle ücret veya vaka üzerindeki bir status change ile takip edilir. | ||
| Neden önemli Kodlamadaki gecikmeler yaygın bir darboğazdır. Bu aktiviteyi takip etmek, kodlama workflow'undaki verimsizlikleri ve bunların faturalama zaman çizelgeleri üzerindeki etkilerini belirlemeye yardımcı olur. Nereden alınır Genellikle hasta vakası veya ücret batch'indeki bir durum değişikliğinden, örneğin 'Uncoded'dan 'Coded'a geçişten çıkarılır. Bu durum değişikliği için bir timestamp gereklidir. Yakala Vaka veya ücret durumunun 'Coded' veya 'Ready for Billing' olarak değişmesinden çıkarılır. Event tipi inferred | |||
| Ret Alındı | Ödeme yapanın, havale bildiriminde belirtildiği gibi, bir talebi veya belirli satır öğelerini reddettiği event'i işaretler. Bu event genellikle havale data'larında bulunan denial code'larından çıkarılır. | ||
| Neden önemli Retleri izlemek, kodlama hataları veya uygunluk sorunları gibi kök nedenleri belirlemek ve temiz talep oranını iyileştirmek için çok önemlidir. Nereden alınır Havale (ERA/835) data'larından çıkarılır. Bir talep veya satır öğesi sıfır olmayan bir ret miktarına ve karşılık gelen bir ret neden koduna sahip olduğunda, bu event tetiklenir. Yakala Ret neden kodları (CARCs/RARCs) içeren havale data'larından çıkarılır. Event tipi inferred | |||
| Ret İtiraz Edildi | Reddedilen bir talebe itiraz edildiğini gösteren bir kullanıcı veya sistem eylemi. Bu genellikle bir durum güncellemesi veya bir iş kuyruğunda oluşturulan belirli bir görev olarak yakalanır. | ||
| Neden önemli Bu aktivite bir yeniden çalışma döngüsünü başlatır. İtirazların sıklığını ve başarı oranını analiz etmek, gelir geri kazanım çabalarını optimize etmek için kritik öneme sahiptir. Nereden alınır Bu, açıkça kullanıcı tarafından başlatılan bir Yakala Bir kullanıcının reddedilen bir talep için itiraz sürecini başlattığında bir durum değişikliği veya kaydedilmiş event. Event tipi explicit | |||
| Tahsilat Aktivitesi Başlatıldı | Hastanın hesabının ödenmeme nedeniyle tahsilat sürecine aktarıldığını gösterir. Bu genellikle hesabın finansal veya durum sınıfındaki bir değişiklikle yakalanır. | ||
| Neden önemli Bu, kötü borçları yönetmek için kritik bir adımdır. Bu aşamaya neyin yol açtığını ve başarı oranını analiz etmek finansal sağlık için hayati öneme sahiptir. Nereden alınır Hesap durumu alanının 'Collections' veya 'Bad Debt' olarak değişmesinden çıkarılır. Bu durum değişikliğinin ilişkili bir timestamp'i olmalıdır. Yakala Bir hesap durumunun 'Collections' veya benzeri bir duruma değişmesinden çıkarılır. Event tipi inferred | |||
| Yakalanan Ücretler | Faturalandırılabilir hizmetlerin veya öğelerin hastanın hesabına girişini temsil eder. Bu, klinik sistemlerden otomatik olarak veya personel tarafından manuel entry yoluyla gerçekleşebilir. | ||
| Neden önemli Bu aktivite, hizmet sunumu ile faturalandırma başlatma arasındaki süre olan 'tahsilat gecikmesini' ölçmek için kritiktir ve nakit akışını ve gelir bütünlüğünü doğrudan etkiler. Nereden alınır Her ücret satır öğesinin oluşturulma timestamp'iyle tanımlanan ücret işlem tablolarından yakalanır. Oracle Health'te bu genellikle ücretle ilgili tablolardadır. Yakala Her yeni ücret için işlem günlüğü girişi oluşturuldu. Event tipi explicit | |||
Veri Çekim Kılavuzları
Adımlar
- Veritabanı Erişim İsteği: Oracle Health Gelir Döngüsü veritabanı için salt okunur kimlik bilgileri edinin. Hasta, vaka, faturalama ve finansal işlem data'larını içeren şemalara erişiminiz olması gerekecektir. Bu genellikle BT güvenliği ve veritabanı yönetim ekiplerinden onay gerektirir.
- Şema ve Tablo Adlarını Belirleyin: Oracle Health kurulumunuz için kesin şema ve tablo adlarını doğrulamak üzere bir veritabanı yöneticisi veya sistem analisti ile çalışın. Sorguda sağlanan adlar yaygın yer tutuculardır ve belirli ortamınıza eşleştirilmelidir.
- Bir SQL İstemcisi Yükleyin: İş istasyonunuza Oracle SQL Developer veya DBeaver gibi uyumlu bir SQL istemcisi yükleyin. Bu araç, veritabanına bağlanmak ve çıkarım betiğini yürütmek için kullanılacaktır.
- Veritabanı Bağlantısı Kurun: Sağlanan ana bilgisayar, port, hizmet adı ve kimlik bilgilerini kullanarak SQL istemcinizde yeni bir veritabanı bağlantısı yapılandırın. Bağlantının başarılı olduğundan emin olmak için test edin.
- SQL Sorgusunu Özelleştirin: Sağlanan SQL betiğini yeni bir sorgu düzenleyici penceresine kopyalayın.
[START_DATE]ve[END_DATE]gibi yer tutucu değerleri bulun ve analiziniz için istenen tarih aralığıyla (örneğin, '2023-01-01') değiştirin. Belirli bir Hasta Sınıfı için filtreleme gibi özel analitik ihtiyaçlarınıza göre filtre koşullarını ayarlayın. - Çıkarım Betiğini Yürütün: Özelleştirilmiş SQL betiğini çalıştırın. Sorgu kapsamlı olacak şekilde tasarlanmıştır ve tarih aralığına ve veritabanınızın boyutuna bağlı olarak tamamlanması birkaç dakikadan birkaç saate kadar sürebilir.
- İlk Sonuçları İnceleyin: Sorgu tamamlandıktan sonra, SQL istemcinizin sonuç tablosundaki ilk birkaç yüz satırı inceleyin. Betiğin doğru çalıştığından emin olmak için tümü boş sütunlar veya yanlış data formatları gibi bariz hataları kontrol edin.
- Data'yı CSV'ye Aktarın: Tüm sonuç setini bir CSV dosyasına aktarın. Karakter sorunlarını önlemek için UTF-8 kodlaması kullanın. Dışa aktarılan dosyanın, sorgu takma adlarında belirtilen sütun adlarını (örneğin, "BillingEvent", "ActivityName") içeren bir başlık satırı içerdiğinden emin olun.
- Yükleme İçin Hazırlık: Bir Process Mining aracına yüklemeden önce, CSV dosyasını bütünlüğünü doğrulamak için açın. timestamp formatının tutarlı olduğunu ve sütun başlıklarının gereken attributes ile tam olarak eşleştiğini kontrol edin. Dosya şimdi upload'a hazırdır.
Konfigürasyon
- Tarih Aralığı: Sorgu
[START_DATE]ve[END_DATE]yer tutucularını kullanır. Veri hacmini kontrol etmek için belirli ve makul bir tarih aralığı tanımlamak kritik öneme sahiptir. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Filtreleme: Başlangıçtaki veri seti,
RelevantEncountersbölümündeki vaka kayıt tarihi (reg_dt_tm) ile filtrelenir. Kapsamı daraltmak için bu bölüme başkaWHEREcümleleri ekleyebilirsiniz, örneğin belirli vaka türlerine odaklanmak içine.patient_class_code IN ('INPATIENT', 'OUTPATIENT')kullanabilirsiniz. - Performans: Üretim sisteminde doğrudan veritabanı sorgulama performansı etkileyebilir. Bu veri çıkarımını yoğun olmayan saatlerde veya varsa üretim veritabanının salt okunur bir kopyası üzerinde çalıştırmanız şiddetle tavsiye edilir.
- Ön Koşullar: Bu yöntem, sorguda referans alınan tüm tablolarda
SELECTayrıcalıklarına sahip bir veritabanı kullanıcı hesabı gerektirir. Bu tablolar vaka, faturalama, ücret, talep, havale ve finansal işlem tablolarını içerir. - Tablo ve Sütun Eşleştirme: Sağlanan betik, tablolar ve sütunlar için yaygın, temsilci adlar kullanır. Bunları kuruluşunuzun Oracle Health veritabanı şemasındaki gerçek adlarla doğrulamanız ve eşleştirmeniz gerekir. Örneğin,
FINANCIAL_TRANSACTIONsisteminizdeAR_TRANSACTIONSolarak adlandırılabilir.
a Örnek Sorgu sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;