I'll start by simply sending our project requirements to provide a framework, then follow it up over the next few days with specific scenarios as requested by Rachel.
I'm guessing that our Health System doesn't qualify as a small provider as Chris & William describe, in that we have adopted the strategy that we will take full responsibility for formatting and batching X12 transactions (and have acquired a product to assist us in doing so). That being done, we will then send them directly to payers, or their designates, for 70%-80% of the claims. The remaining 20%-30% will be routed to one or more clearing houses which we will select via RFP (to be issued this spring). So, our requirements are fairly straight-forward, and I will state them relative to the business process that they relate to: Business Process: Registration / Admission - get insurance information Requirement: Recognizable code from card(s) or responsible party(parties) The key fields that most (all but 2) of our billing applications have room to code are: payer id, plan id, group id, and member id, and a contact phone number. Four of the applications have a space for address, but that appears to be intended for postal address, so its of no help. The "identification" we are looking for is to be able to take information from the card and relate it to an address where we can check coverage & co-payments. Today, that identification is a phone number which is often on the card, but often not (in which case we look it up in our payer files within the different applications). In the brave new world of EDI, i expect the information to ultimately resolve to an address (and protocol) where I can send an X12n-270 (real-time or batch). Business Process: Registration / Admission - verify coverage & co-pay Requirement: Resolve card information to 270 address (or comparable contact identifier) I should note here that the 270IG on page 12 tells me pretty clearly that the 2000A entity is where the message is to be sent to get the answers. Figuring out what this entity is, however, is an interesting trick for reasons noted by others in this listserv - a single payer can have a multitude of other entities that are the brokers of this information. With no disrespect to Kepa's proposed DNS model (which i really do like), i'm not so sure that the payers even know enough about their own plans to know who to send eligibility inquiries to - at least our registration folks often seem to "know" that for certain payers, they don't even bother to call the payer's information number - they call the employer's HR department to get the appropriate contact number. It seems to me that the entity that prints the card is responsible for supplying the appropriate contact information on the card (agree that bar code or mag stripe would be helpful additions, but would, themselves, require more standards to be useful). The need for a real-time verification varies between our providers - in most non-emergent cases we need to know coverage before or concurrent with when service is rendered. Once we establish coverage for a patient, that information is saved in our various vendor applications for review/use during the next encounter. Business Process: Review & Authorization Requirement: <We have not examined this transaction yet - primarily because our business office has indicated that whenever reviews or referral requests are made, they must be accompanied by other clinical documentation (i.e. physician's care plan / discharge summary / op notes, etc, depending upon circumstance and payer or TPA), and consequently the transaction itself sans the other documentation is of little value>. Business Process: Billing - identify destination for the claim Requirement: Resolve original information received to an address where the claim is to be sent. Presently, we make some specific distinctions between Medicare, Medicaid, and some health plans (hard-coded in some of the billing applications), grouping them separately because they go electronically to different places today. In the future, we would expect to resolve the identifier addresses to physical destinations when the nightly "sweep" of our "ready to bill" claims takes place, packaging all claims for a particular payer-destination (again, for a single payer, the destinations can vary greatly depending on plan and group). We would certainly favor William Kammerer's simpler model of having the payers give us one single address, and having them take on the burden of appropriate routing, but as I said before, we have little confidence that they even know the correct address themselves. Business Process: Billing - verify receipt of the claim Requirement: Use standard X12n response (the 997) to verify that the group of claims reached their intended target. Requirement: Verify that the end-point destination payer (the one who is going to generate the RA) is in receipt of the claim. If the X12n-997 only tells us that the "next-hop" receiver got the claims, and we don't see other acknowledgements in the chain, i'm not clear how we meet the second requirement short of the 276, and even that is problematic as explained below. Business Process: Timed follow-up on unresolved claims Requirement: Use standard X12n-276 sent to "last known" end-point. The intention is to use a parameter in our A/R applications, which is set by payer & plan, to trigger non-response follow-ups, much as we do manual phone & letter follow-ups today. The problem that needs to be resolved is where the 276 is sent. If the original endpoint for the transaction is not the entity that actually cuts the check (a 3rd party administrator, for example), we need some positive transaction from them that tells us the claim has moved along to the next stop. We find that out today when we call and they tell us it was sent on to the payer. I assume that in the electronic world we'll get either an unsolicited 835 or at least a 277? That assumption in place, the 276 would always be sent to the original claim destination unless advised otherwise by transaction or the trading partner agreement. Business Process: A/R - process unsolicited requests for information and statuses from payers. Requirement: Receive electronic 277s and route to the appropriate application internally for handling. Note here that many of our smaller application vendors as yet have no clue what the 277 is/does. Our initial thought is that we'll create an internal email notification to most of our A/R depts. that can't handle electronic 277s with human-readable interpretation of the 277 information. It would be much better, however, if we could somehow indicate to the senders when we cannot accept certain transactions for certain entities. Business Process: A/R - record payments to claims Requirement: Receive electronic 835, route it to the proper system internally for posting. Here, again, while we are making better progress with the application vendors in this area, we do not expect all of them will be able to upload 835 information, and we will have to be able to print a human-readable version of the transaction (and have acquired a program to do so). Lastly, i'm somewhat concerned with the notion of disregarding the legacy dial-up applications since i'm quite sure that batch submission through dial access will continue to be a primary vehicle for submitting claims in at least the near future. Communications technology has far surpassed the ability of most healthcare software vendors, and i don't see bread-and-butted healthcare A/R applications moving rapidly into the near-real time transaction space (you might guess that i'm underwhelmed thus far in the responses from our various software vendors). Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240
