Let’s jump right back into the thick of this topic. In the first part of this blog series, we discussed why insurers should be empowering their customers to complain in fairly general terms. Check out the link to our Decision Maker’s Guide to Complaint Enablement for more background on this topic.
This post dives deeper into a few key metrics: retention rates, customer lifetime value, and quantity of feedback gathered. To do so, we’ll take a look at the financial impact of non-complainers. While you read, it may also be helpful to consider whether you are currently measuring or utilizing any data to achieve similar goals.
Before getting to specifics, here’s a quick recap of what was covered last time:
D. Power’s 2018 research tells us that the industry average score for providing a satisfying purchase experience is 839 out of 1,000.1
Microsoft recently announced the end of support (EOS) for SQL and Windows 2008. What does that mean for you? Maybe nothing, but if your company is currently running either version you need to consider your options. There are two important dates to make note of – July 9th and January 14th. SQL Server 2008 support ends on July 9, 2019 and Windows Server 2008 support ends January 14, 2020. Option 1 is to migrate to Azure. When you’re ready to, you can modernize your applications. Option 2 is to continue to run on 2008 until support ends and then decide. We can help to weigh your options.
Are you ready to get started? We can help!
What are HIPAA SNIP types? We get this question a lot, so we’ve been blogging about the different categories WEDI has defined to validate healthcare EDI transactions. Thus far, we’ve covered:
SNIP 1 & 2 Integrity and Requirement Testing
SNIP 3 Claim Balancing
SNIP 3 Remittance Advice Balancing
SNIP 4 Intersegment Situational Testing
SNIP 5 External Code Set Testing
These rules are sometimes referred to as SNIP levels – although that may wrongly imply that each type builds upon the previous category. In actuality, each SNIP type is a standalone set of validations rules.
In this article, we’ll focus on SNIP 6.
SNIP 6 enforces situational rules specific to service lines and products. While SNIP 4 also focuses on situational rules that analyze the relationships between loops, segments and elements, SNIP 6 differs in that the rules apply to subsets within the transaction sets.
For example, within an 837…
Workers compensation claims contain a special set of requirements when submitted in the EDI 837 format. This article describes these specific characteristics.
In a standard 837, the 2000B loop always contains subscriber information (the primary insured individual). Claim level information (2300 loop) is nested beneath the 2000B loop in this scenario. The 2000C (Patient) loop is present in the case in which the claim is related to a dependent of the subscriber. In these cases, the 2300 loop is nested under 2000C. In workers comp claims, a 2000B and 2000C loop always exist, and their purposes are a bit different. Information related to the employer goes into the 2000B loop, while the 2000C loop is used for the claimant (the injured worker). The concept of a dependent doesn’t exist in workers comp claims.
The SBR segment present in 2000B is a required…
Here’s an interesting fact from a Forbes article published earlier this year, regarding end-consumers in the insurance industry:
“91% of non-complainers just leave”1
This tells us that there are two types of customers in the insurance world: complainers, and non-complainers. Among non-complainers, more than nine out of ten actively choose to take their business to another company. The insurer they leave behind must deal with the following consequences:
Loss of future revenue streams
Lack of insight into why the customer chose to leave in the first place
The significance these metrics have on bottom line revenue can’t be understated. These are customers that were already paying for a service – that had already gone through a decision-making process, chosen one insurer, and were so dismayed with some aspect of their service that they chose to begin this entire search process again.
But there’s a simple…
Each day health plan administrators look forward to the challenge of loading 834 enrollments and 837 claims into their adjudication systems.
From a distance, it seems simple to report and reconcile the EDI transactions submitted by providers and clearinghouses through a plan’s intake workflow. Drilling into the steps along the inbounding process, challenges emerge which can present insurmountable obstacles to answering a question as basic as: How long has this claim been held up in my intake process?
TriZetto QNXT is a common adjudication platform we’ll use to illustrate this point. In a typical workflow, loading claims might involve:
Handoff: The day’s 837s are pulled from an SFTP server and moved to the start of the intake process.
Archive: Move files into processing workflow, and archive a copy.
EDI Structural Validation – Basic checks are performed to ensure the 837 transactions are well-formed. This level of validation is…
It’s taken a year for me to feel confident enough to even chime in, on a high level, about the products we’ve created, and the platforms we utilize. I can dabble in conversation about chatbots and Microsoft’s Cognitive Services. I understand now, more or less, what ‘the cloud’ is and its benefits. But, this is why teamwork makes the dream work, you know. My colleagues can build you a solution to any business challenge. Anything. You’ve got a problem, they’ll solve it.
But, now it’s my turn. I am going to express why what they can do matters.
You’ve all heard of Machine Learning. We partnered with RetailWire to produce a Webinar on ML for Retail back in April and that’s where my understanding really began to take shape. In a nutshell, Machine Learning can be set-up and do in minutes and…
SQL Server’s AlwaysOn technology (available since SQL Server 2012) provides high-availability and disaster-recovery database functionality which largely supplants mirroring and log-shipping – in fact, mirroring is now deprecated. Exactly what functionality is available and how robust it is, varies by release (2012+), edition (Standard versus Enterprise) and the physical infrastructure devoted to it. AlwaysOn is fairly easy to set up (though it requires cooperation from both Windows Server and networking admins) and, relative to the required effort, provides exceptional durability for SQL Server databases. AlwaysOn is not a complete OOTB durability solution and has significant gaps – e.g. it does not maintain SQL Server logins and roles synchronized across multiple servers – but it is an excellent start for the needs it caters to.
This post assumes the reader has at least a basic familiarity with SQL Server backups, as well…
When the Health Insurance Exchange (HIX) network went online in late 2013, the industry was challenged with reconciling new subscribers to their related premium payments and subsidies. Health plans painstakingly assembled Excel eligibility extracts to invoice their Federally Facilitated Marketplace (FFM) or State-based Exchange (SBE) for tax credit reimbursement. However, by the start of 2016, the FFM became the system of record for eligibility, and issuers were required to accept a new variant of EDI representing premium payments.
Traditionally, the 820-Payment Order / Remittance Advice transaction (005010X218) has been transmitted from payroll agencies and government healthcare organizations to insurers in order to provide summary or subscriber-level information regarding premium payments. With the advent of ACA exchanges, enough variations surfaced in this traditional handshake that a new version of the 820 was required. The HIX 820 (005010X306) removes structures unnecessary for exchange reporting, and adds tracking segments for the unique aspects of these plans, such as…