ClearingHouses Are Oxymorons

Understanding #HealthIT is daunting to say the least. At PokitDok, we work hard to take the burden off the developer. The only difference between health IT apps and other apps is the data that flows through them. The biggest impediment we see to the nimble development of third party health IT applications is in the area of eligibility, claims and benefits processing, also known as clearinghouse services. This, ladies and gents, is not to be confused with the Publishers Clearing House - though with both, there tend to be massive checks involved.

Today, clearinghouses serve as an integral - yet fundamentally flawed, part of a health service transaction. To that end, our engineering team has rewritten the entire specification based on present day software principles.

Being the inquisitive type, I let Google do the hard work and searched for “clearinghouse.”  Let’s have a look at the results from Dummies.com,  shall we?

“In medical billing, companies that function as intermediaries who forward claims information from healthcare providers to insurance payers are known as clearinghouses. In what is called claims scrubbing, clearinghouses check the claim for errors and verify that it is compatible with the payer software.“

If you have experience with health IT, you understand the above explanation - and that is based on 1970s edi (electronic data interchange). The healthcare focus was later added in the early 1990s. See the DISA website for the succinct history.

If you don’t have health IT experience, then this may seem somewhat opaque and unnecessary/over-complicated when compared to a services based industry. And indeed, you would be right.  The original process is an anomaly in most current transactional and consumer driven industries.

If you’re developing almost any type of health application from Bionic Vision (SecondSight) to music therapy (Neurorhythm), you’ll need to cover the basics - eligibility through claims submission. PokitDok handles all of these processes and more via our APIs. Even if you are steeped in health IT software development, think carefully:  

Does your current “clearinghouse” support the ability to track the actual activities of the specific transactional processes of the eligibility and claims?

Do you even know the response times of the payers?

What’s so clear anyway about this clearinghouse process?

Here is where the plot thickens:

When PokitDok set out to build all of the services required to power a 1-click purchase of healthcare services and the ability for anyone to utilize this data through any third party developed application, we knew we had to build a modern day CLEAR-inghouse. I emphasize CLEAR here, as we want to be as transparent (ha) as possible.

When we set out to provide clearinghouse services via APIs for developers, we knew providing activity information and up to the millisecond dashboards would be imperative. As a result, our APIs nominally run anywhere from 460-600ms, depending on network access and JSON payload. Refer to our status page for a comparison of Payers and the z-score aggregate times we track on a monthly basis.

We wanted all types of application developers to be able to utilize this data to create personalized healthcare experiences for the consumer, for it is the consumer who owns this data and who benefits from these software processes. Providers, of course, also benefit - as, the better the software, the better the experience - for everyone.

As stated, the overarching design goal for all of our APIs and processing is that they will be used to personalize consumer transactions, whatever the relative utility or asset is defined to be. Therefore, real-time response is paramount. A great example, of this real-time response, is our Activity API.

Available modes of operation: real-time

Long-running operations are performed asynchronously. So, if you do have something that takes longer than say, 600ms - we’ve got you covered. Upon initiating those operations via an API endpoint, activity tracking information is returned to the caller, which can be used to query the status of the activity later.

This allows you, the developer, to check on and query the analytics of the processing of the respective ASC 5010 X12 calls whether they’re eligibility, claims or referrals. Here is a visual of the actual dashboard you get (free of charge):

Screen Shot 2016-05-04 at 11.49.35 AM

Figure 1.0 Developer Analytics Dashboard

So, why is this important from a both a developer and operations standpoint? Let’s say, for instance, that you provide revenue cycle workflow management. You can access that via dashboard analytics or put together a flow of endpoints that are able to analyze any ‘choke points’ in the event processing and revenue life cycle. Previously, this was unavailable and there were no _activities_ associated with the processing.

The endpoints associated with activities across the board for all of our APIs, including X12, are as follows:

Endpoint HTTP Method  Description
/activities/ GET List current activities A query string parameter ‘parent_id’ may also be used with this API to get information about sub-activities that were initiated from a batch file upload.
/activities/{id} GET Return detailed information about the specified activity. API applications will receive an activity ID in the API response for all operations that are asynchronous.
/activities/{id} PUT Updates an existing activity – useful for canceling pending activities that a client application no longer wishes to execute

 

Here’s another view into the data with respective activities being presented:

Screen Shot 2016-05-04 at 11.40.51 AM

A very interesting and useful aspect of the way we designed our system was the use of callback URLs.

Field Type Description
callback_url {string} URL that will be invoked to notify the client application that this Activity has completed. You should always use https for callback URLs used by your application.

 

NOTE: You should always use https for callback URLs used by your application.

Suppose you, the developer, were writing an application that processes claims and you tried to submit a claim request that contained a callback_URL_value. When we (PokitDok) get a response to your applications claim back from the trading partner (aka payer), we will POST the results back to your callback_url so you, dear developer, don't have to poll the activities API for status updates to the the respective claim being processed. Further, in cases where you’ve registered for claims payments, we make two callbacks, one for the original claim acknowledgment and another for the final claim payment info to be sent hopefully through our fully compliant PCI payment API, such that the payer, provider and consumer can all be cleared appropriately on the services rendered.

NOTE: We also provide batch mode for those companies that have not updated their infrastructure or processing requirements to current day performance standards. We do hope however, that you will.

We hope this provides you with a brief glimpse into how most present day healthtech companies should be providing transparency, and dare I say clarity, into their processing. We will be delving further into this area in the next blog but suffice to say if your clearinghouse provider does not provide these basic present day software utilities for activities and analytics, you should absolutely seek other solutions.

Sign up for the PokitDok Platform for a free trial period and unlimited free-of-charge X12 transactions or contact us with any questions.

 

About Ted Tanner

Ted Tanner is co-founder and CTO of PokitDok. Ted is an engineering executive with extensive experience ranging from startups to public corporations. Focused mainly on growth scale computing he has held architect positions at both Apple and Microsoft and has held instrumental roles in several start-ups, including digidesign (IPO and acquired by Avid), Crystal River Engineering (acquired by Creative Labs), VP of R&D at MongoMusic (acquired by Microsoft) and Co-founder and CTO of BeliefNetworks (acquired by Benefitfocus). He was also the CTO of Spatializer Audio Labs (NASDAQ: SPAZ), a company specializing in digital signal processing solutions. He is on the IAB for the University of South Carolina Computer Science Department as well as the Center for Intelligent Systems and Machine Learning at the University of Tennessee. Mr. Tanner has published numerous articles in leading technical magazines and holds several patents in the areas of semantics, machine learning, signal processing and signal protection.

View All Posts

Leave a Reply

Your email address will not be published.