Gelir Döngüsü Yönetimi Veri Templateiniz
Gelir Döngüsü Yönetimi Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Oracle Health Revenue Cycle için veri çıkarma yönergeleri
Gelir Döngüsü Yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Gelir döngüsü sürecinde gerçekleşen belirli adımın veya olayın adıdır. | ||
| Açıklama Bu öznitelik, faturalandırma olayının yaşam döngüsünde gerçekleştirilen her etkinliğin adını kaydeder. Örnekler arasında 'Ücret kalemleri kaydedildi', 'Talep ödeme sorumlusuna gönderildi' ve 'Ödeme kaydedildi' yer alır. Bu etkinlikler, keşfedilen süreç haritasının düğümlerini oluşturur. Etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining çalışmalarının temelini oluşturur. Bu öznitelik en sık izlenen süreç yollarını belirlemeye, standart prosedürden sapmaları ortaya çıkarmaya ve gelir döngüsünün işleyişini anlamaya yardımcı olur. Neden önemli? Süreç adımlarını tanımlar; süreç haritasını görselleştirmenizi ve iş akışı örüntülerini analiz etmenizi sağlar. Nereden alınır? Genellikle olay günlüklerinden, durum değişikliği kayıtlarından veya Oracle Health’te gelir döngüsünün farklı aşamalarıyla ilişkili işlem tablolarından elde edilir. Örnekler Talep oluşturulduÖdeme bildirimi alındıRet kararına itiraz edildiHesap kapatıldı | |||
| Faturalandırma olayı BillingEvent | Ücret doğuran tek bir hizmet veya ürün sunumunu tanımlayan benzersiz kimliktir. Gelir döngüsü sürecinde vaka kimliği olarak kullanılır. | ||
| Açıklama Faturalandırma olayı, ana vaka kimliği olarak işlev görür ve belirli bir faturalandırılabilir kalem için ücret kaydından hesabın kapatılmasına kadar tüm etkinlikleri birbirine bağlar. Her faturalandırma olayı, gelir döngüsü sürecinin benzersiz bir örneğini temsil eder. Böylece talep gönderimi, ödeme kaydı, olası retler ve düzeltmeler gibi farklı aşamalardaki ilerleme izlenebilir. Process Mining analizinde bu öznitelik, uçtan uca süreç akışını yeniden oluşturmanın temelini oluşturur. Süreç varyantlarını görselleştirmeyi, etkinlikler arasındaki çevrim sürelerini hesaplamayı ve belirli faturalandırma olaylarıyla ilişkili darboğazları veya sapmaları belirlemeyi sağlar. Neden önemli? Faturalandırılabilir bir hizmetin tüm yaşam döngüsünü izlemek için gereken temel anahtardır; süreç akışı analizini ve performans ölçümünü mümkün kılar. Nereden alınır? Bu tanımlayıcı, Oracle Health Gelir Döngüsü içindeki temel faturalandırma veya ücret işlemi tablolarında bulunan benzersiz bir anahtar olmalıdır. Ücret olaylarının birincil anahtarını belirlemek için sistem dokümantasyonuna başvurun. Örnekler BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Olay zaman damgası EventTimestamp | Bir etkinliğin sistemde kaydedildiği kesin tarih ve saat. | ||
| Açıklama Bu öznitelik, her etkinliğin zaman damgasını sağlayarak gerçekleştiği kesin anı belirtir. Belirli bir faturalandırma olayının gelir döngüsündeki olayların zamanlamasını ve sırasını anlamak için gereklidir. Analizde Olay zaman damgası, etkinlikleri kronolojik sıraya koymak, farklı adımlar arasındaki süreleri ve çevrim zamanlarını hesaplamak ve darboğaz analizi yapmak için kullanılır. 'Talep gönderildi' ile 'Ödeme bildirimi alındı' arasındaki gecikmeleri belirlemek gibi zamana dayalı tüm Process Mining metriklerinin temelini oluşturur. Neden önemli? Olayları sıralamak, çevrim süreleri ve süreler gibi performans metriklerini hesaplamak ve süreç darboğazlarını belirlemek için bu zaman damgası gereklidir. Nereden alınır? Oracle Health Gelir Döngüsü’ndeki her işlem veya olay günlüğü tablosunda, kaydın oluşturulduğu ya da olayın gerçekleştiği zamanı gösteren bir zaman damgası sütunu bulunmalıdır. Örnekler 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Düzeltme tutarı AdjustmentAmount | Hesap bakiyesine uygulanan düzeltmelerin parasal değeri. | ||
| Açıklama Bu öznitelik, sözleşme indirimleri, silinen borçlar veya düzeltmeler gibi faturalama olayına uygulanan finansal düzeltmelerin tutarını kaydeder. Düzeltmeler, bir ücret karşılığında beklenen geliri doğrudan azaltır. Hesap düzeltmelerinin etkisini gösteren Dashboard, büyük ölçüde bu özniteliğe dayanır. Düzeltme tutarlarını ve bunların nedenlerini incelemek; gelir kaybı kaynaklarını, sözleşme yönetimindeki sorunları veya ilk ücret kaydı sürecindeki aksaklıkları belirlemeye yardımcı olur. Finansal sağlığın temel metriklerinden biridir. Neden önemli? Silinen borçlar veya düzeltmeler nedeniyle oluşan gelir kaybını ölçer, finansal erimenin temel nedenlerini belirlemeye ve gidermeye yardımcı olur. Nereden alınır? Hasta hesabına uygulanan düzeltmeleri veya silinen borçları kaydeden finansal işlem tablolarında bulunur. Örnekler -50.25-120.0025.00 | |||
| Faturalandırma departmanı BillingDepartment | Etkinlikten sorumlu departman veya işlevsel ekip. | ||
| Açıklama Bu öznitelik, etkinliği gerçekleştiren 'Ücret kaydı', 'Kodlama' veya 'Tahsilat' gibi departmanı belirtir. Süreç akışına kurumsal bir bağlam kazandırır. Süreci departman bazında analiz etmek, ekipler arasındaki devir teslimleri anlamak ve departmanlar arası verimsizlikleri belirlemek açısından önemlidir. Etkinliklerin ve performans metriklerinin departman düzeyinde toplanmasını sağlayarak 'Faturalandırma departmanı iş yükü' Dashboardunu destekler. Neden önemli? Etkinlikleri kurumsal birimlerle ilişkilendirir. Bu, departmanlar arası devir teslimleri, iş yükünü ve ekip performansını analiz etmek için önemlidir. Nereden alınır? Bu bilgi Oracle Health’te doğrudan kullanıcı profili verilerinde saklanabilir veya kullanıcıya ya da etkinlik türüne göre belirlenebilir. Örnekler Hasta kabulKodlamaFaturalandırmaTahsilat | |||
| Hasta sınıfı PatientClass | Yatan hasta veya ayakta tedavi gören hasta gibi, hasta başvurusunun sınıflandırması. | ||
| Açıklama Bu öznitelik, ücrete neden olan hasta ziyaretinin veya başvurusunun türünü sınıflandırır. Yaygın sınıflar arasında yatan hasta, ayakta tedavi gören hasta, acil hasta ve düzenli hasta bulunur. Hasta sınıfı, faturalandırma ve talep gönderimi sürecinin tamamını belirleyebilir. Farklı hasta sınıfları farklı süreç yollarını izler ve farklı uyumluluk gerekliliklerine tabidir. Süreci bu özniteliğe göre analiz etmek, farklılıkları anlamaya, iyileştirme çalışmalarını ihtiyaca göre düzenlemeye ve her sınıf için doğru prosedürlerin izlenmesini sağlamaya yardımcı olur. Neden önemli? Yatan ve ayakta tedavi gören hastalar gibi; karmaşıklığı, zaman çizelgesi ve faturalandırma gereklilikleri farklı olan süreç akışlarını birbirinden ayırır. Nereden alınır? Oracle Health’te hasta başvurusu veya kabul kaydıyla ilişkili standart bir alandır. Örnekler Yatan hastaAyakta tedavi gören hastaAcilTekrarlayan | |||
| Kullanıcı UserPerformingAction | Etkinliği gerçekleştiren kişinin kullanıcı kimliği veya adı. | ||
| Açıklama Bu öznitelik, süreçte belirli bir etkinliği gerçekleştirmekten sorumlu çalışanı veya otomatik sistem kullanıcısını tanımlar. İş yükü dağılımını ve kaynak performansını anlamak, eğitim ihtiyaçlarını belirlemek açısından önemlidir. Analizde bu öznitelik, süreç haritasını kullanıcıya veya ekibe göre filtrelemeyi, farklı kaynakların performansını karşılaştırmayı ve 'Faturalandırma departmanı iş yükü' Dashboardu için iş yükünü incelemeyi sağlar. En iyi performans gösterenleri veya ek desteğe ya da eğitime ihtiyaç duyabilecek kişileri belirlemeye yardımcı olabilir. Neden önemli? Süreç etkinliklerini belirli kullanıcılarla veya ekiplerle ilişkilendirerek iş yükü analizini, performans karşılaştırmasını ve eğitim fırsatlarının belirlenmesini sağlar. Nereden alınır? Kullanıcı kimliği alanları (ör. 'CREATED_BY', 'USER_ID') genellikle Oracle Health modüllerindeki işlem tablolarında bulunur. Örnekler j.doeasmithBillingBot_AUTOk.williams | |||
| Ödeme sorumlusunun adı PayerName | Ödemeden sorumlu sigorta şirketinin veya üçüncü taraf ödeme sorumlusunun adı. | ||
| Açıklama Bu öznitelik, hizmet için fatura gönderilen sigorta şirketi veya Medicare gibi devlet programı gibi kuruluşu tanımlar. Ödeme sorumlusu bilgileri, gelir döngüsü analizinin temelini oluşturur. Süreci ödeme sorumlusuna 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 yol açan ödeme sorumlularını belirlemeye yardımcı olur ve ödeme sorumlularıyla yapılan sözleşmeleri ve ilişkileri etkili biçimde yönetmek için gereklidir. Neden önemli? Süreci ödeme sorumlusuna göre gruplandırarak farklı işleyişleri, ret oranlarını ve ödeme hızlarını ortaya çıkarır. Bu bilgiler finansal performansı değerlendirmek açısından önemlidir. Nereden alınır? Bu bilgi, Oracle Health Gelir Döngüsü’ndeki hasta faturalandırma veya sigorta kayıtlarında saklanır. Örnekler AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Ödenmemiş bakiye OutstandingBalance | Belirli bir andaki faturalama olayı için kalan ödenmemiş bakiye. | ||
| Açıklama Bu öznitelik, tüm ödemeler ve düzeltmeler uygulandıktan sonra faturalama olayı için hâlâ ödenmesi gereken tutarı gösterir. İlgili ücret için mevcut alacak tutarını ifade eder. Bu öznitelik, Ödenmemiş bakiye yaşlandırma Dashboardu için büyük önem taşır. Değerin zaman içindeki değişimini incelemek, nakit akışının hızını izlemeye, tahsilat çalışmalarının etkinliğini değerlendirmeye ve Satışların Tahsilat Süresi (DSO) gibi temel finansal KPI’ları hesaplamaya yardımcı olur. Neden önemli? Her vaka için mevcut alacak tutarını izler; nakit akışını yönetmek ve tahsilat çalışmalarının etkinliğini analiz etmek için gereklidir. Nereden alınır? Bu değer genellikle belirli bir faturalama olayına ait tüm finansal işlemlerin (ücretler, ödemeler ve düzeltmeler) toplamından hesaplanır. Hesap özeti tablosunda bir alan olarak da bulunabilir. Örnekler 75.000.00550.80 | |||
| Ret nedeni kodu DenialReasonCode | Ödeyicinin bir talebi hangi nedenle reddettiğini belirten standart kod. | ||
| Açıklama Ödeyici bir talebi reddettiğinde, kapsam dışı hizmet veya yinelenen talep gibi ret nedenini açıklayan bir kod verir. Bu öznitelik, kodu ve ilgili açıklamayı kaydeder. Ret nedenlerini incelemek, gelir döngüsünü iyileştirmek için temel önemdedir. Kuruluşun kodlama veya hasta uygunluğu sorunları gibi yaygın örüntüleri belirlemesine ve gelecekteki retleri önlemek için düzeltici adımlar atmasına yardımcı olur. Bu da doğrudan hatasız talep oranını artırır ve yeniden çalışma maliyetini düşürür. Neden önemli? Talep retlerinin temel nedenini gösterir; hatasız talep oranını artırmak ve geliri daha hızlı tahsil etmek için hedefli iyileştirmeler yapılmasını sağlar. Nereden alınır? Bu bilgi, ödeyiciden elektronik ödeme bildirimi (ANSI 835 dosyası) olarak alınır ve Oracle Health içindeki talep veya ödeme bildirimi tablolarında saklanmalıdır. Örnekler CO-16: Talep/hizmet, değerlendirme için gerekli bilgileri içermiyor.PR-96: Kapsam dışı ücret(ler).CO-18: Yinelenen talep/hizmet. | |||
| Hasta kimliği PatientId | Faturalama olayıyla ilişkili hastanın benzersiz tanımlayıcısı. | ||
| Açıklama Bu öznitelik, hizmeti alan hastanın benzersiz tanımlayıcısıdır ve genellikle Tıbbi Kayıt Numarası (MRN) olarak bilinir. Finansal işlemi belirli bir kişiyle ilişkilendirir. Sürecin vaka kimliği olmasa da Hasta kimliği, hastanın tüm faturalama olaylarını bir araya getirerek finansal sürecin bütününü anlamaya yardımcı olur. Hasta ana verileriyle birleştirildiğinde demografik bilgilere veya geçmişe göre segmentasyon yapılmasını da sağlar. Neden önemli? Finansal olayları belirli bir hastayla ilişkilendirir; hasta odaklı analiz yapılmasını ve hastanın tüm faturalama işlemlerinin bir araya getirilmesini sağlar. 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 bulunur. Örnekler MRN-1002345MRN-1002346MRN-1002347 | |||
| İtiraz nedeni DisputeReason | Müşterinin veya hastanın bir faturaya ya da ücrete itiraz ederken belirttiği neden. | ||
| Açıklama Bu öznitelik, hastanın veya ödemeden sorumlu başka bir tarafın faturaya neden itiraz ettiğini kaydeder. Nedenler arasında hatalı ücretler, sunulmayan hizmetler veya sigorta işlemlerindeki sorunlar yer alabilir. Bu bilgi, Fatura itirazlarını çözme metrikleri Dashboardu için gereklidir. İtirazların en yaygın nedenlerini anlamak, ücret kaydı, kodlama veya faturalama süreçlerindeki sistematik sorunları belirlemeye yardımcı olur. Temel nedenleri gidermek, itiraz oranını ve çözüm için gereken idari iş yükünü önemli ölçüde azaltabilir. Neden önemli? Faturalara neden itiraz edildiğini açıklar; düzeltilmesi gereken faturalama doğruluğu veya açıklığı sorunlarını doğrudan ortaya koyar. Nereden alınır? Bu bilgi muhtemelen Oracle Health içindeki vaka yönetimi veya müşteri hizmetleri modülünde, hastanın hesabıyla bağlantılı olarak saklanır. Örnekler Hizmet yanlış faturalandırıldıYinelenen ücretSigorta yanlış faturalandırıldıHizmet sunulmadı | |||
| Kaynak sistem SourceSystem | Olay verilerinin çıkarıldığı sistem. | ||
| Açıklama Bu öznitelik, verilerin geldiği kaynak uygulamayı veya modülü belirtir. Bu süreçte kaynak genellikle 'Oracle Health Gelir Döngüsü' olur; ancak veriler birden fazla yerden birleştiriliyorsa sistem içindeki farklı modüller de belirtilebilir. Bu bilgi, veri yönetişimi ve sorun giderme açısından faydalıdır. Verinin kaynağını doğrulamaya yardımcı olur ve birden fazla sistemin uçtan uca sürece katkıda bulunduğu ortamlarda önem taşır. Neden önemli? Verinin kaynağı hakkında bilgi verir. Bu bilgi, veri doğrulama ve yönetişiminin yanı sıra sisteme bağlı olabilecek süreç farklılıklarını anlamak için önemlidir. Nereden alınır? Genellikle Veri Seti kaynağını belirtmek için veri çıkarma, dönüştürme ve yükleme (ETL) işlemi sırasında eklenen sabit bir değerdir. Örnekler OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Olay bitiş zamanı EventEndTime | Varsa, bir etkinliğin tamamlandığı anı gösteren zaman damgası. | ||
| Açıklama StartTime bir etkinliğin başlangıcını, EventEndTime ise bitişini gösterir. Birçok etkinlik anlık gerçekleştiğinden hepsinin ayrı bir bitiş zamanı yoktur. Ancak işlenmesi zaman alabilen 'Ret kararına itiraz edildi' gibi etkinliklerde bu alan oldukça faydalıdır. Bu öznitelik, tek tek etkinliklerin işlem süresini daha doğru hesaplamayı sağlar. Bekleme süresiyle (etkinlikler arasındaki süre) işlem süresini (bir etkinlik üzerinde harcanan süre) birbirinden ayırmaya yardımcı olur. Neden önemli? Bir etkinliğin tamamlanmasının ne kadar sürdüğünü doğrudan hesaplamayı ve işlem süresini bekleme süresinden ayırmayı sağlar. Nereden alınır? Oracle Health Gelir Döngüsü’ndeki bazı işlem tablolarında, belirli ve uzun süren görevler için hem başlangıç hem de bitiş zaman damgası bulunabilir. Örnekler 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Otomatik mi IsAutomated | Etkinliğin otomatik bir sistem veya insan kullanıcı tarafından gerçekleştirilip gerçekleştirilmediğini belirten bir işaret. | ||
| Açıklama Bu mantıksal öznitelik, botlar veya sistem toplu işleri gibi yazılım otomasyonlarının yürüttüğü etkinlikleri, kullanıcıların elle gerçekleştirdiği etkinliklerden ayırır. Örneğin, Talep oluşturuldu etkinliği otomatik bir adım olabilirken Ret için itiraz edildi etkinliği muhtemelen elle gerçekleştirilir. Bu özniteliği incelemek, süreçteki otomasyon düzeyini ve bunun verimlilik ile hata oranları üzerindeki etkisini anlamaya yardımcı olur. Otomatik ve elle yürütülen yolların performansını karşılaştırmak ve yeni otomasyon fırsatlarını belirlemek için kullanılabilir. Neden önemli? İnsanların gerçekleştirdiği etkinliklerle sistemlerin yürüttüğü etkinlikleri ayırır; otomasyonun etkinliğini analiz etmek ve yeni otomasyon fırsatlarını belirlemek için önemlidir. Nereden alınır? Bu değer genellikle UserPerformingAction özniteliğinden türetilir. Örneğin, SYSTEM veya RPA_BOT gibi kullanıcı kimlikleriyle gerçekleştirilen etkinlikler otomatik olarak işaretlenir. Örnekler truefalse | |||
| Son veri güncellemesi LastDataUpdate | Bu olaya ait verilerin en son yenilendiği veya çıkarıldığı zamanı gösteren zaman damgası. | ||
| 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 ne kadar güncel olduğunu anlamak açısından önemlidir. Kullanıcılar, en güncel süreç bilgilerini görüntülediklerini doğrulamak için bu özniteliği kontrol edebilir. Verilerin ne kadar yeni olduğuna ilişkin beklentileri yönetmeye yardımcı olur ve veri yönetişimiyle kalite güvencesinin önemli bir parçasıdır. Neden önemli? Verilerin güncelliğini göstererek analizlerin ve kararların güncel bilgilere dayanmasını sağlar. Nereden alınır? Bu, genellikle verileri Process Mining platformuna yükleyen ETL işlemi sırasında oluşturulan ve doldurulan bir meta veri alanıdır. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Talep kimliği ClaimId | Ödeyiciye gönderilen sigorta talebinin benzersiz tanımlayıcısı. | ||
| Açıklama Bu öznitelik, geri ödeme almak üzere oluşturulup ödeyiciye gönderilen talebe atanan benzersiz kimliktir. Örneğin düzeltme gerektiğinde, tek bir faturalama olayı yaşam döngüsü boyunca bir veya daha fazla talep oluşturabilir. Talep kimliği, ödeyiciye yapılan belirli bir gönderimin izlenmesini ve ödeme ya da ret gibi yanıtlarla doğrudan ilişkilendirilmesini sağlar. Daha geniş gelir döngüsü sürecinde daha ayrıntılı izleme olanağı sunar. Neden önemli? Bir talebin ödeyiciyle olan sürecini izlemek için özel bir tanımlayıcı sağlar; bu, genel faturalama olayına göre daha ayrıntılı izleme olanağı sunar. Nereden alınır? Bu kimlik, talep oluşturulduğunda Oracle Health tarafından üretilir ve ana talepler tablosunda saklanır. Örnekler CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Ücret tutarı ChargeAmount | Faturalanan hizmetin veya ürünün brüt parasal değeri. | ||
| Açıklama Bu öznitelik, herhangi bir düzeltme, sözleşme indirimi veya ödeme uygulanmadan önce hizmet için alınan ilk, indirimsiz tutarı gösterir. Faturalama olayının başlangıçtaki finansal değeridir. Ücret tutarını izlemek, sunulan hizmetlerin toplam değerini hesaplamak ve sonraki düzeltmelerin ya da silinen borçların finansal etkisini anlamak gibi finansal analizler için önemlidir. Gelirin gerçekleşme düzeyini ölçmek için temel oluşturur. Neden önemli? Vakanın başlangıçtaki finansal değerini belirler; bu değer, sonraki tüm finansal analizler ve etki değerlendirmeleri için temel oluşturur. Nereden alınır? Oracle Health içindeki ücret ayrıntısı veya ücret işlemi tablolarında bulunur. Örnekler 150.001250.7585.50 | |||
| Yeniden çalışma mı IsRework | Yeniden çalışmayı veya tekrarlanan çabayı gösteren etkinlikleri belirten bir işaret. | ||
| Açıklama Bu hesaplanan öznitelik, ideal yoldan sapmayı ve yeniden çalışmayı gösteren etkinlikleri işaretler. Düzeltilmiş talep gönderildi veya Ret için itiraz edildi gibi etkinlikler, süreç ilk seferde sorunsuz ilerleseydi gerçekleşmezdi. Yeniden çalışmayı belirlemek ve ölçmek, Process Mining çalışmalarının temel hedeflerinden biridir. Bu işaret, tüm yeniden çalışma döngülerini kolayca filtreleyip analiz etmenizi sağlar; böylece süreç verimsizliklerinin sıklığını, maliyetini ve nedenlerini ölçebilirsiniz. Gelir döngüsünde kalitenin gerçek maliyetini anlamak için gereklidir. Neden önemli? Yeniden çalışma döngülerinin sıklığını ve etkisini ölçmeye yardımcı olur; süreç verimsizliklerini ve düşük kalitenin maliyetini ortaya çıkarır. Nereden alınır? Bu, türetilmiş bir özniteliktir. Veri dönüştürme sırasında, belirli etkinlik adlarını yeniden çalışma olarak işaretleyen iş mantığı uygulanarak hesaplanır. Örnekler truefalse | |||
Gelir Döngüsü Yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hasta başvurusu oluşturuldu | Belirli bir ziyaret veya hizmet için hasta hesabının oluşturulduğunu gösterir. Bu, genellikle kayıt sistemi ya da Hasta Kabulü/Taburcu/Transfer (ADT) veri akışı tarafından tetiklenen açık bir olaydır. | ||
| Neden önemli? Belirli bir faturalandırma olayı için tüm gelir döngüsünün başlangıç noktasıdır. Toplam süreç süresinin ve kayıt doğruluğunun analiz edilmesini sağlar. Nereden alınır? Hasta Kayıt veya ADT modülü günlüklerinden alınır. Başvuru oluşturma olaylarını ya da başvuru veya finans numarasıyla ilişkili en erken zaman damgasını bulun. Kaydedin Hasta kaydı veya kabulü sırasında günlüğe kaydedilen olay. Olay türü explicit | |||
| Hesap kapatıldı | Hesap bakiyesinin sıfırlandığını ve başka işlem beklenmediğini gösteren son etkinliktir. Genellikle hesap bakiyesinin sıfıra ulaşmasından anlaşılır. | ||
| Neden önemli? Gelir döngüsünün başarıyla tamamlandığını gösterir. Bu aşamaya ulaşma süresi, genel süreç verimliliğinin önemli bir ölçüsüdür. Nereden alınır? Genellikle tüm ödemeler ve düzeltmeler işlendiğinde hesabın ödenmemiş bakiyesinin ilk kez sıfıra indiği ve sıfır kaldığı an belirlenerek anlaşılır. Kaydedin Tüm ücret kalemleri ve ödemeler kaydedildikten sonra hesap bakiyesi ilk kez sıfıra eşitlendiğinde hesaplanır. Olay türü calculated | |||
| Ödeme kaydedildi | Ödeme sorumlusundan alınan ödemenin hasta hesabındaki ilgili ücret kalemlerine işlenmesini ifade eder. Bu finansal işlem bir kullanıcı veya otomatik süreç tarafından kaydedilir. | ||
| Neden önemli? Ödeme kaydetme verimliliği, alacak hesaplarının doğruluğunu etkiler. Buradaki gecikmeler finansal görünümü bozabilir ve ikincil faturalandırmayı geciktirebilir. Nereden alınır? Ödeme işlemi tablolarında bulunur. Her ödeme kaydının benzersiz bir işlem kimliği ve ilişkili bir zaman damgası vardır. Kaydedin Ödeme hesaba işlendiğinde finansal işlem kaydedilir. Olay türü explicit | |||
| Talep ödeme sorumlusuna gönderildi | Oluşturulan talebin sigorta şirketine veya ödeme sorumlusuna elektronik ya da basılı olarak gönderilmesini ifade eder. Sistem, bu iletimin tarih ve saatini kaydetmelidir. | ||
| Neden önemli? Bu etkinlikle ödeme döngüsü başlar. Gönderimden ödemeye kadar geçen süreyi analiz etmek, ödeme sorumlusunun performansını ve Satışların Tahsilat Süresini (DSO) anlamak açısından önemlidir. Nereden alınır? İletim olaylarını kaydeden talep yönetimi modülünden alınır. Talep geçmişinde gönderim zaman damgasını veya durumun 'Gönderildi' olarak değiştiği kaydı bulun. Kaydedin Talep takas odası üzerinden başarıyla iletildiğinde günlüğe kaydedilen olay. Olay türü explicit | |||
| Talep oluşturuldu | Ücret kalemlerinin UB-04 veya CMS-1500 gibi resmi bir faturalandırma talebinde bir araya getirildiği noktayı gösterir. İlk faturayı oluşturan bu olay sistem tarafından kaydedilir. | ||
| Neden önemli? Ödeme sorumlusuna faturalandırmaya hazır olunduğunu gösteren önemli bir aşamadır. Kurum içindeki ücret kaydından faturalandırmaya kadar geçen süreyi ölçmek için bitiş noktası olarak kullanılır. Nereden alınır? Talep oluşturma günlüklerinde veya tablolarında açıkça kaydedilen bir olaydır. Başvuruyla ilişkili ana talep kaydının oluşturulma zaman damgasını bulun. Kaydedin Talep kaydı oluşturulduğunda günlüğe kaydedilen olay. Olay türü explicit | |||
| Düzeltilmiş talep gönderildi | Genellikle ret kararının veya ek bilgi talebinin ardından ödeme sorumlusuna gönderilen gözden geçirilmiş ya da düzeltilmiş talebi ifade eder. Düzeltme göstergesi içeren yeni bir talep gönderimiyle belirlenir. | ||
| Neden önemli? Bu etkinlik, ret yönetimindeki yeniden çalışma döngüsünün önemli bir parçasıdır. Sık tekrarlanması, ilk talep bilgilerinin doğruluğunda sorun olduğuna işaret eder. Nereden alınır? Talep gönderim günlüklerinden alınır. Genellikle yeniden gönderim kodu veya daha yüksek bir yineleme numarasıyla işaretlenen, mevcut bir başvuruya ait yeni gönderimi bulun. Kaydedin Talebin yeniden gönderilmesiyle ilgili günlüğe kaydedilen olaydır. Genellikle belirli bir talep sıklığı türü koduyla belirlenir. Olay türü explicit | |||
| Hasta hesap özeti gönderildi | Hastanın ödemesi gereken kalan tutar için fatura oluşturulup hastaya gönderildiğini gösterir. Bu işlem, hasta faturalandırma modülünde açıkça kaydedilir. | ||
| Neden önemli? Bu etkinlikle gelir döngüsünün hasta ödemelerine ilişkin bölümü başlar. Bu adımı izlemek, hasta tahsilatlarının etkinliğini analiz etmeye yardımcı olur. Nereden alınır? Hasta faturalandırma veya yazışma günlüklerinden alınır. Sistem, her hesap özetinin oluşturulduğu veya gönderildiği tarihi kaydetmelidir. Kaydedin Hasta hesap özeti oluşturulup basıldığında veya elektronik olarak gönderildiğinde günlüğe kaydedilen olay. Olay türü explicit | |||
| Hesap bakiyesi düzeltildi | Sözleşme indirimi, silinen borç veya indirim gibi, hesap bakiyesinde yapılan finansal düzeltmeyi ifade eder. Her düzeltme ayrı bir finansal işlemdir. | ||
| Neden önemli? Düzeltmeler geliri doğrudan etkiler. Sıklıklarını, türlerini ve tutarlarını analiz etmek, gelir kayıplarını ve faturalandırma 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 zaman damgasıyla ayrı bir kalem olarak kaydedilir. Kaydedin Belirli bir düzeltme koduyla finansal işlem kaydedilir. Olay türü explicit | |||
| Ödeme bildirimi alındı | Ödeme sorumlusundan Elektronik Ödeme Bildirimi (ERA) veya basılı Haklar Açıklaması (EOB) alındığını gösterir. Bu belgede hangi ücret kalemlerinin ödendiği, reddedildiği veya düzeltildiği belirtilir. | ||
| Neden önemli? Bu, ödeme sorumlusundan gelen ilk yanıttır. Ödeme hızını anlamak ve ret eğilimlerini erkenden belirlemek açısından önemlidir. Nereden alınır? Ödeme bildirimi işleme modülünde kaydedilir. Talebe bağlı 835 işlem dosyası gibi ERA dosyasının içe aktarılma veya oluşturulma zaman damgasını bulun. Kaydedin Ödeme sorumlusunun ödeme dosyası (ör. ANSI 835) içe aktarılıp işlendiğinde günlüğe kaydedilen olay. Olay türü explicit | |||
| Ret kararına itiraz edildi | Reddedilen bir talebe itiraz edildiğini gösteren kullanıcı veya sistem işlemidir. Genellikle durum güncellemesi ya da iş kuyruğunda oluşturulan belirli bir görev olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik, yeniden çalışma döngüsünü başlatır. İtirazların sıklığını ve başarı oranını analiz etmek, gelir tahsilat çalışmalarını iyileştirmek açısından önemlidir. Nereden alınır? Bu, kullanıcının başlattığı açık bir olay olabilir veya talep durumunun 'İtiraz edildi' ya da 'İnceleniyor' olarak değişmesinden anlaşılabilir. Kaydedin Kullanıcı reddedilen bir talebe itiraz sürecini başlattığında kaydedilen durum değişikliği veya olay. Olay türü explicit | |||
| Tahsilat süreci başlatıldı | Ödeme yapılmaması nedeniyle hasta hesabının tahsilat sürecine alındığını gösterir. Bu durum genellikle hesabın finansal sınıfındaki veya durum sınıfındaki değişiklikle kaydedilir. | ||
| Neden önemli? Tahsil edilemeyen borçları yönetmek için önemli bir adımdır. Bu aşamaya yol açan nedenleri ve tahsilat başarı oranını analiz etmek, finansal sağlığı korumaya yardımcı olur. Nereden alınır? Hesap durumu alanının 'Tahsilat' veya 'Şüpheli alacak' olarak değişmesinden anlaşılır. Bu durum değişikliğiyle ilişkili bir zaman damgası bulunmalıdır. Kaydedin Hesap durumunun 'Tahsilat' veya benzer bir duruma geçmesinden anlaşılır. Olay türü inferred | |||
| Talep reddi alındı | Ödeme bildiriminin gösterdiği üzere, ödeme sorumlusunun bir talebi veya belirli kalemleri reddettiği olayı belirtir. Bu olay çoğu zaman ödeme verilerindeki ret kodlarından anlaşılır. | ||
| Neden önemli? Retleri izlemek, kodlama hataları veya uygunluk sorunları gibi temel nedenleri belirlemek ve hatasız talep oranını artırmak için gereklidir. Nereden alınır? Ödeme bildirimi (ERA/835) verilerinden anlaşılır. Bir talep veya kalem için ret tutarı sıfırdan büyükse ve buna karşılık gelen bir ret nedeni kodu varsa bu olay tetiklenir. Kaydedin Ret nedeni kodlarını (CARC/RARC) içeren ödeme bildirimi verilerinden anlaşılır. Olay türü inferred | |||
| Ücret kalemleri kaydedildi | Faturalandırılabilir hizmetlerin veya kalemlerin hasta hesabına eklenmesini ifade eder. Bu işlem klinik sistemlerden otomatik olarak ya da personel tarafından elle yapılabilir. | ||
| Neden önemli? Bu etkinlik, hizmetin sunulmasıyla faturalandırmanın başlaması arasındaki süre olan ücret kaydı gecikmesini ölçmek açısından önemlidir. Bu süre, nakit akışını ve gelir doğruluğunu doğrudan etkiler. Nereden alınır? Ücret işlemi tablolarından alınır ve her ücret kaleminin oluşturulma zaman damgasıyla belirlenir. Oracle Health’te bu bilgi genellikle ücretle ilgili tablolarda bulunur. Kaydedin Her yeni ücret kalemi için işlem günlüğü kaydı oluşturulur. Olay türü explicit | |||
| Ücret kalemleri kodlandı | Tıbbi kodlama uzmanlarının kaydedilen ücret kalemlerine CPT veya ICD-10 gibi standart kodlar atadığı süreci ifade eder. Bu işlem genellikle ücret kaleminin veya başvurunun durumundaki değişiklikle izlenir. | ||
| Neden önemli? Kodlamadaki gecikmeler sık görülen bir darboğazdır. Bu etkinliği izlemek, kodlama iş akışındaki verimsizlikleri ve bunların faturalandırma takvimine etkisini belirlemeye yardımcı olur. Nereden alınır? Genellikle hasta başvurusunun veya ücret grubunun durumundaki değişiklikten anlaşılır; örneğin 'Kodlanmadı' durumundan 'Kodlandı' durumuna geçiş. Bu durum değişikliğinin zaman damgası gerekir. Kaydedin Başvuru veya ücret durumunun 'Kodlandı' ya da 'Faturalandırmaya hazır' olarak değişmesinden anlaşılır. Olay türü inferred | |||
Veri çıkarma kılavuzları
Adımlar
- Veritabanı erişimi isteyin: Oracle Health Revenue Cycle veritabanı için salt okunur kimlik bilgileri alın. Hasta, karşılaşma, faturalama ve finansal işlem verilerini içeren şemalara erişmeniz gerekir. Bunun için genellikle BT güvenlik ve veritabanı yönetimi ekiplerinin onayı gerekir.
- Şema ve tablo adlarını belirleyin: Oracle Health örneğinizde kullanılan kesin şema ve tablo adlarını doğrulamak için bir veritabanı yöneticisi veya sistem analistiyle çalışın. Sorguda verilen adlar yaygın yer tutuculardır; kendi ortamınızdaki adlarla eşleştirmeniz gerekir.
- SQL istemcisi yükleyin: Oracle SQL Developer veya DBeaver gibi uyumlu bir SQL istemcisini iş istasyonunuza yükleyin. Bu araçla veritabanına bağlanıp veri çıkarma betiğini çalıştıracaksınız.
- Veritabanı bağlantısı kurun: Sağlanan ana bilgisayar, bağlantı noktası, 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ğunu doğrulamak için test edin.
- SQL sorgusunu özelleştirin: Sağlanan SQL betiğini yeni bir sorgu düzenleyicisi penceresine kopyalayın.
[START_DATE]ve[END_DATE]gibi yer tutucuları bulun ve analiziniz için istediğiniz tarih aralığıyla değiştirin (ör. '2023-01-01'). Belirli bir Patient Class değerine göre filtreleme gibi analiz ihtiyaçlarınıza uygun filtre koşullarını düzenleyin. - Veri çıkarma betiğini çalıştırın: Özelleştirdiğiniz SQL betiğini çalıştırın. Sorgu kapsamlı olacak şekilde tasarlanmıştır; tarih aralığına ve veritabanınızın boyutuna bağlı olarak tamamlanması birkaç dakika ile birkaç saat sürebilir.
- İlk sonuçları inceleyin: Sorgu tamamlandığında SQL istemcinizin sonuç tablosundaki ilk birkaç yüz satırı inceleyin. Betiğin doğru çalıştığından emin olmak için tümüyle boş sütunlar veya hatalı veri biçimleri gibi belirgin sorunları kontrol edin.
- Verileri CSV’ye aktarın: Sonuç kümesinin tamamını CSV dosyasına aktarın. Karakter sorunlarını önlemek için UTF-8 kodlaması kullanın. Dışa aktarılan dosyada sorgu takma adlarında belirtilen sütun adlarını içeren bir başlık satırı bulunduğundan emin olun (ör. "BillingEvent", "ActivityName").
- Yükleme için hazırlayın: Process Mining aracına yüklemeden önce CSV dosyasını açıp bütünlüğünü kontrol edin. Zaman damgası biçiminin tutarlı ve sütun başlıklarının gerekli özniteliklerle birebir aynı olduğunu doğrulayın. Dosya artık yüklemeye hazırdır.
Yapılandırma
- Tarih aralığı: Sorguda
[START_DATE]ve[END_DATE]yer tutucuları kullanılır. Veri hacmini kontrol etmek için belirli ve makul bir tarih aralığı tanımlamanız önemlidir. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Filtreleme: İlk veri seti,
RelevantEncountersbölümünde karşılaşma kayıt tarihi (reg_dt_tm) kullanılarak filtrelenir. Kapsamı daraltmak için bu bölüme başkaWHEREkoşulları ekleyebilirsiniz. Örneğin, belirli karşılaşma türlerine odaklanmak içine.patient_class_code IN ('INPATIENT', 'OUTPATIENT')koşulunu kullanabilirsiniz. - Performans: Üretim sisteminde doğrudan veritabanı sorgusu çalıştırmak performansı etkileyebilir. Bu veri çıkarma işlemini yoğun olmayan saatlerde veya varsa üretim veritabanının salt okunur kopyasında çalıştırmanız önemle önerilir.
- Ön koşullar: Bu yöntem için sorguda başvurulan tüm tablolarda
SELECTayrıcalığı olan bir veritabanı kullanıcı hesabı gerekir. Bu tablolar arasında karşılaşma, faturalama, ücret, talep, ödeme bildirimi ve finansal işlem tabloları bulunur. - Tablo ve sütun eşlemesi: Sağlanan betikte yaygın ve örnek niteliğinde tablo ve sütun adları kullanılır. Bunları kuruluşunuzun Oracle Health veritabanı şemasındaki gerçek adlarla doğrulayıp eşlemeniz gerekir. Örneğin, sisteminizde
FINANCIAL_TRANSACTIONtablosunun adıAR_TRANSACTIONSolabilir.
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; Başlamaya hazır mısınız?
Verilerinizi doğru biçimde hazırlamak için bu Templateten yararlanın. Gelir Döngüsü Yönetimi sürecinizi bugün iyileştirmeye başlayın.
Daha hızlı ödeme almak için gelir döngünüzü iyileştirin
Darboğazları ortadan kaldırın, çevrim süresini %30 azaltın ve nakit akışını artırın.
Kredi kartı gerekmez. Kurulumu birkaç dakika içinde tamamlayın.