William,
 
If you recall, there was discussion about how information is processed
prior to the lookup.  To solve the routing issues, must we first
understand the process that occurs before routing can begin?  Should we
identify and validate our assumptions about the pre-routing process?  It
seems the information gathering process that occurs before a transaction
set can be submitted via an exchange header will significantly impact
the type of information needed in a directory or CPP.  
 
Do we need to understand the difference between the major models of
insurance - i.e. Employer Sponsored(HMO, PPO), Self-Insured,
Medicare/Medicaid, etc. and what type of information is necessary to
properly identify the Plan that covers the patient?
 
Do we get input from the provider side as to the typical processes used
to gather insurance information?  What types of information can you
typically rely on from the patient to identify the appropriate Plan? 
How do you get that plan information today?  Which types of plans are
the most difficult to collect information about?  

What percentage of the 30% non-card carrying patients do the providers
simply "Patient bill", and then let the patient deal with the insurance
company?
 
Would this be within scope of our initiatives?
 
So many questions, so little time....

-Ronald Bowron

>>> "William J. Kammerer" <[EMAIL PROTECTED]> 04/29/02 10:13AM >>>

Peter Barry and I presented a session on Identifiers, EDI Addressing
and 
Routing at the Fourth National HIPAA Summit at the Renaissance Marriott

in Washington, DC. last Friday. See http://www.hipaasummit.com/ for 
more information about the HIPAA Summit. The presentation slides 
themselves are available as a PDF file at http://www.novannet.com/wedi/
, 
by selecting "Identifiers, EDI Addressing, and Routing Presentation." 
Like most Powerpoint slides, they are of limited usefulness unless you

have the audio tape - which is available from HIPAA Summit for a price.


Peter covered the National Plan and Provider IDs, their enumeration,
and 
the database requirements for their maintenance and I followed up with

an overview of some of our plans from the Joint WEDI/SNIP and AFEHCT ID

& Routing Special Interest Group. 

Folks did seem to doubt that anything as ambitious as our Healthcare 
directory and electronic Trading Partner profile could be available by

the time H-day rolls around. I emphasized that the registry and 
electronic profiles will be usable in a manual fashion, where CPPs can

be viewed with XSLT style sheets. Most of the value of the registry is

just in the ability to locate trading partners' profiles - we don't
need 
to wait for software vendors to update their software for completely 
automating the "Discovery" process. 

We've been assuming all along that providers would have no problem 
"identifying" payers and plans, figuring that each patient carries his

insurance card around with him (and that the cards would have the EDI 
identifier printed on them). But we've been disabused of that notion by

comments at the meeting - either patients don't have their insurance 
cards 30% of the time, or the information that the provider has on file

for them is woefully out of date. Pharmacy, according to David 
Feinberg, maintains a centralized database to solve this problem: 
apparently, insurance companies load demographic information about
their 
covered subscribers at some clearinghouse for shared access by 
pharmacies. 

Of course, this isn't the problem we're trying to solve (of patients
not 
carrying their insurance card). We can make the assumption that the 
provider has some means of determining some ID of the plan or payer 
applicable to the particular patient. But to help things along, we may

want to add searching by payer name as a requirement - to accommodate 
the situation where the patient knows the name of his plan or insurance

company: refined searches in the registry can locate the actual CPP 
covering the plan to which eligibility inquiries can be sent. 

William J. Kammerer 
Novannet, LLC. 
+1 (614) 487-0320 



Reply via email to