Overview
Organization
The SNIP ID & EDI Address project is cooperating with another project called
the AFEHCT-WEDI Health Care Communications Security and Interoperability
project.
The Problem
This document would include background
on the existing Healthcare EDI environment (where we are), the ideal
(where we want to go), Identifiers as they relate to routing of
transactions, a high-level description of an Electronic Partner Profile,
a high-level description of the Healthcare Registry, along with some
examples of how all this would look in practice.
So I think what the team is trying to do is define a neutral, efficient
technology that can serve both now and in the future, and that will be a
significant achievement.
Judging from our conversations over the last few months, it seems folks
have a "problem" finding out how to exchange EDI transactions with their
partners without burdensome and manual processes. If that's not a
problem - i.e., either the processes are not that manual or burdensome,
or just not worth fixing considering the exigencies of other HIPAA
issues - then there's no need to devise requirements for a solution to
an imaginary problem. And if there's no problem to solve, then there's
certainly no need to deliver a solution "within any acceptable
timeframe."
Either manual
EDI enrollment processes are a problem, or they aren't. If they are, I
believe that an open standard based on a Registry of electronic partner
profiles is an effective technical solution worth pursuing by the
WEDI/SNIP ID & Routing SIG.
This effort is/should
be substantially above the business data level and be dealing with message
addressing and various transport methods that may be supported/required by a
trading partner.
Furthermore, the scope of this effort should not be limited to the HIPAA
transactions, but serve all of health care.
Motivation
(1) How would a provider know where to even send a standard transaction
to whatever entity handles them on behalf of the plan or payer?
(2) A payer might have multiple "portals" for different types of
transactions (say, "real-time" vs. batch) - how does he convey that to
any provider who might want to send standard transactions?
(3) How does a payer know whether a provider even supports EDI in the
first place?
(4) Assuming a provider *does* EDI, how would a payer know that a
particular provider supports particular transactions (e.g, an 835 EOB -
there's nothing in the 837 which says 835s are expected in return).
Where would the payer send the transactions?
(5) How would a payer or provider tell trading partners the
communication protocols he supports? If he's using some of dial-up
system, how does he convey logon IDs and passwords? Where does his X.509
digital ID public key reside?
(6) How does a payer say what his requirements are for ISA and GS
fields? How can he tell the provider that he can't handle more than
5000 claims in an individual 837?
(7) How does someone report errors beyond the standard TA1 and 997? Does
he support the 824? Or e-mail? - if so, what e-mail address should be
used for sending error messages?
You can add "or his agent" (such as a Clearinghouse, repricer or Third
Party Administrator) to "provider" or "payer" above. This list
certainly isn't exhaustive - I'm not the keenest when it comes to
keeping crap organized, and Microsoft Project would only confuse me.
Any of these problems can be solved the old fashioned way: through
telephone calls, e-mail and paper TPAs. They can sometimes be delegated
to one's Clearinghouse. On the other hand, if we agree that paper TPAs,
paper "Companion" documents and lots of e-mail and phone tag are
undesirable, we might ask if any or all of these problems can be solved
in an automated fashion. Or - along the road to complete automation of
EDI enrollment - can this information be advertised somehow where
partners know where to look? Can it be expressed in a mechanical
fashion for consistency and rudimentary automation?
Do you agree that these are problems at least some payers and providers
would like to see resolved? If any of these struck a chord, then our
proposed solution - which entails recommendations based on the open
ebXML CPP (electronic Partner Profile) and Registry specifications seems to satisfy many of the requirements posed by the problems. Do you
have alternative solutions? Are these problems so critical to solve
that a solution has to be in place by April 2003?
Standard Transactions
HIPAA mandates the NCPDP Retail Pharmacy electronic transactions between
pharmacists and payers for eligibility, claims and remittance advices.
Some of the hesitance to venture into NCPDP
may simply be due to ignorance on our part, considering most of us are
X12 types! Maybe there's no problem at all integrating NCPDP's needs on a first-class basis - within our Healthcare CPP Registry.
Thanks for clarifying what you mean by "all of health care." We now
know you certainly did not mean NCPDP, HL7 or Healthcare supply-chain.
If I hear you correctly, I think you're saying we should accommodate the
non-HIPAA (or yet to be HIPAA) X12N administrative transactions (like
the 277/275 claims attachment and the 269 "COB"), in addition to the
"final" HIPAA X12 transactions, in the recommendations we will develop
for solving whatever problem we haven't determined yet. I would fully
and enthusiastically concur.
For example, even though the NCPDP retail pharmacy transaction is a
HIPAA standard transaction, we haven't discussed it much. Can somebody
enlighten us on how it is currently used? Are Clearinghouses involved?
Can a pharmacy be treated like any other provider? How are NCPDP
transactions packaged and identified?
Information Flow
Multiple 837s could result in a single 835,
couldn't they? Claims could be sent throughout the day to the payer,
with the payer waiting to process them in one run, resulting in a single
835 which the provider has to reconcile with any number of claims (sent
in any number of 837s).
The 837 ceases to exist by the time it gets to adjudication: it has
decomposed into any number of atomic claims. There's nothing to say an
835 reflects only claims from one 837 - and there's really no reason for
the payer to retain any notion that a particular claim came from any
particular 837. And this is in the direct point-to-point scenario
between provider and payer, with no intervening Clearinghouse which may
be munging claims together from multiple providers for the payer! Bob
Poiesz has emphatically taught us that the 837 is nothing but an
ephemeral package encapsulating any particular claim - only until the
next moment when it is possibly captured in another 837's orbit.
But fortunately, I don't think we have to peer at the atomic level for
solving our routing problems. We're only concerned with the physics of
moving intact X12 transactions. The interaction P-->A-->P should
really be decomposed into two separate (and possibly unrelated)
sequences:
Provider ->(837) Payer
Payer ->(835) Provider
We can't afford to ignore the technical acknowledgements in our
information flows involving the 997 and the TA1 (and maybe even the
824). In the simplest cases where individual 837s are packaged in a
single interchange, diagramming the interaction might be simple:
Provider ->(837) Payer ->(997) Provider
But what about when multiple transactions (and multiple transaction
types - i.e., a mixture of 837s and 270s) are packaged in a single
interchange? I don't think that really complicates things, in that all
we really wanted to demonstrate is that the 997s (plural) go back to
whoever sent the original interchange.
You are correct when discussing an "837" as opposed to an atomic claim. My
"flows" analysis was meant to show the routes that an atomic claim/payment
or eligibility request/response traverse in our health system today, whether
electronic or paper or phone. In fact, even when on paper, we tend to print
/ accumulate paper claims for a specific payer in a sequence that allows
stuffing them into a single envelop when mailing (roughly equivalent to an
837). When the envelop reaches the payer, they open it and the "integrity"
of that 837 grouping is lost the moment that the individual paper claims
flow into their intake process (e.g. they are scanned into their electronic
applications).
The 997 / TA1 is a concept that has no equivalence in the paper world, but
does in the telephone inquiry - it is the acknowledgement that our admission
& A/R follow-up people manually record when they call a payer to check on
eligibility & claim receipt.
What you bring to light is the difference between what I am describing as
the atomic "flows", wherein a certain event such as a claim would be
expected to elicit a payment (or at least an RA) response, and the
communication of that event between trading partners. As you correctly point
out, an 837 (which I would look at as a package of 1 or more atomic claims),
could elicit any number of responses: a 997, several 835s, 277s, and even
278s to TPAs and 837s to COB payers. These "response" events are temporally
disconnected and unrelated to the original 837. What they each do have,
however, is a specific relationship back to the atomic events that were
gathered in the original 837 package.
Getting back to the "business requirement" here, I need to determine (using
a definition here for "transaction" as the single atomic event that needs
communication):
1) the final destination for each transaction to be sent; then,
2) based on that final destination (through some mechanism that will be
engineered from the business requirements) discover the entry point address
for each transaction to be sent; then
3) group the transactions by entry point address; then
4) create the electronic packages by entry point address; then
5) send the packages using methods described in my trading partner profile
for each entry point address.
For the packages sent, I would expect to get (depending on the trading
partner profile) a 997 for each package sent (regardless of destination).
From that point on, each atomic transaction sent out is monitored
individually, without regard to the "package" it was sent in. In fact, we
should not care at all how the transactions are repackaged and re-routed by
the intervening parties as long as each transaction arrives expeditiously
(I'd like to define that term at some point...) at the final destination.
When we receive a package of transactions from wherever, a 997 would be sent
as an acknowledgement of receipt. Again, other than our sending of a 997 to
the sender of the package, we would assume that the contents of the package
have no particular relationship to each other. The package would then be
parsed into its atomic transactions, each transaction attached to its
initiating event, and each would finally be distributed to the originating
application for automatic processing.
The 270/271 and the 276/277 allow for multiple Information
Sources and Information Receivers. There is no concept here of routing
an ISA from Provider (or direct agent) to Payer (or direct agent). One
interchange (or transaction) can be for multiple final receivers and
from multiple original submitters. There is NOT a guaranteed one to one
relationship beyond the point to point of any specific leg of the
ultimate path.
Transport
HIPAA is silent when it comes to just how standard transactions are to
be sent. So EDI could be sent via dial-up BBS, e-mail, bi-synch 3780,
FTP, X.25, EDIINT, or whatever. But, generally, if you want to send
direct to the payer (point-to-point), the payer dictates the protocol.
Because of the multitude of various protocols, and the difficulty of
finding the EDI "addresses" of trading partners, most providers will
probably choose to use a Clearinghouse.
It's unrealistic to restrict transport methods to the common TCP/IP
protocols. We need to support all the "legacy" dial-up connection
types - to assuage fears of the open Internet's security "problems" or
to simply support the PM systems out there already - with some means of
describing scripts, logins, passwords, modem-settings, etc. etc. in our
Electronic Trading Partner Agreement.
Of course, I want to emphasize again that we are only concerned with the
packaging, routing and securing of STANDARD (HIPAA X12 and NCPDP)
transactions between any two entities. We are not looking at
situations where practice management software is generating or receiving
proprietary formats through a CH; proprietary links (those not using
standard transactions) to a CH or business associate are out of scope.
We are, after all, the Workgroup for "Electronic Data Interchange."
I'll ask again what I asked on the 11th: "...does anyone know of any
OASIS, W3C, IETF, etc. effort for devising XML files to describe all
communication capabilities of a partner? .... I want to see something
that says 'this is a dial-up using Kermit with this phone number.'
Surely someone has devised a schema for describing communication
capabilities. There's no sense in us reinventing the wheel."
As an aside, Dick Brooks has in the past brought up the need to assign a
username/password to each trading partner before granting access to a
B2B server - how is this to be automated, and what effect does this have
on the use of electronic Trading Partner Agreements? Maybe userids and
passwords could be avoided altogether if B2B servers were somehow to
employ digital certificates instead for granting access - e.g., they
could grant access to legitimate providers who hold one of those
AMA/Verisign issued digital certificates.
Otherwise, if someone wants to ensure ahead of time who will be sending
transactions before assigning a userid and password, then there seems to
be no way around some kind of manual interaction - whether it is a
paper TPA or a web registration. At least an Electronic Trading Partner
Agreement could give the URL where a provider is to manually register,
so the userID and password can be e-mailed.
1.) How many of you are planning to use a VAN?
2.) How many will just set up an ftp server on your network and let trading
partners drop off their files and pick up their files from a trading partner
specific outbox?
For the latter, you can put into the identifiers whatever you want. This is
my intent for a payer solution that I am writing.
It's cheap, (free, the ftp server comes with Windows/linux/Unix).
Privacy is an issue that I could overcome with encryption but I don't want
to touch this issue right now, maybe in two weeks.
3.) Are there other routing and EDI transport mechanisms out there that I
forgot? Maybe email attachments? Those would be easy to encrypt at least.
Work Product
Technically, this group is a WEDi/SNIP Business Issues SIG (Special
Interest Group) for the purpose of developing a white paper to address
the standard transaction routing problem. When I say we're going to
develop a "White Paper," I'm just parroting what the BI leadership says
we're to do. I would imagine they (BI) want a White Paper which
describes the perceived problems, if any, with regard to identification
and routing, and some suggestions for solving these problem(s).
This project will publish implementation guidelines for (1) an
Electronic Trading Partner Agreement (e-TPA) specification to
mechanically configure communication and translation
software, and (2) automatic "discovery" mechanisms for locating
Trading Partners' e-TPAs on the Internet based on their
business identifiers.
Our near-term plan is to generate four "working" papers. These papers
will eventually be combined into a "white" paper or recommendation
containing implementable specifications for the Healthcare CPP
electronic partner profile and Registry. The four working papers cover:
(1) Identifiers
(2) Addresses and delivery channels
(3) Elements of the Healthcare Collaboration-Protocol Profile (CPP)
(4) "Discovery" of Healthcare CPPs (i.e., the Registry)
It's my opinion that the urgent problem to be addressed and solved **before
April, 2003** is how to complement the current business model **using the
X12 Interchange control envelope** for the submission of claims and without
forcing the entire industry on its head...there are sufficient challenges
with just adopting a new set of formatting rules and standard data. Coming
up with a "down and dirty" (if necessary) solution that will enable the
industry to become operational today should be the urgent priority of this
group.
Critical Success Factors
dream of frictionless e-commerce "without the need for
bilateral Trading Partner agreements" - hopefully, what we do here in
WEDI/SNIP will resuscitate his hopes
Critical Success Factors:
* Provide basic core functions initially -- Give marketplace participants
what they need to solve their current problems
* Recognize that IT alone won’t produce optimal pricing and efficiency in
the market -- User acceptance more critical than implementation of IT
* Infrastructure should complement existing trade value chain
* Infrastructure should provide for end-to-end integration of business
applications & information sharing in value chain -- Must be able to be
integrated into back-office applications of participants
* Effective ownership and control of infrastructure -- Participants must
have a perceived or real vested interest in infrastructure, both business
and technical
* Accurate, objective identification -- Marketplace accepted standardized
product identification is crucial
(I believe this factor can equally be applied to HIPAA's challenge of
identifiers, whether for product/service or entity. A major issue and
challenge for all industries as they move into the electronic information
exchange world is unambiguous and accepted identifiers: for all the players,
delivery end points, billing and paying entities, and for the products
and/or services moving through the value chain. For HIPAA, I believe the
medical code sets are the analogy to product/service identifiers. We're
still awaiting the national identifiers for payers and providers - but we do
know what the key characteristics of these identifiers most likely will be
and we can begin planning to accommodate them in our respective systems.
There is no mystery as to what the identifier will be for employers.)
* Fulfillment of strong, genuine existing need in marketplace -- Don’t use
electronic market system/infrastructure to replace existing market practice
* Satisfaction of need overarching critical success factor
Perhaps these learnings from other efforts can help inform this group's
efforts towards coming up with solutions to solve the immediate needs as
well as looking to the future. If the solution is only to the future, I
don't believe it will be accepted by the industry.
Thus, I would suggest that the priority focus should be on coming up with an
immediate (and even perhaps interim) solution that will address the need for
identifiers that can be used to enable the correct routing of HIPAA
transactions to the intended and correct receiving system and which also are
complementary to today's business model. It seems to me that a key
characteristic of today's business model is that the industry (whether it's
a clearinghouse or other intermediary, or the provider, or the payer) does
not use an enveloping scheme that in any way parallels the X12 enveloping
structures with their ability to logically identify the sender and receiver.
As a result, other mechanisms have evolved to get the transaction to the
intended final destination. Perhaps it would be worthwhile to more fully
understand how it works today and how today's mechanisms can be exploited in
the near/short term to enable the players to become operational with the
HIPAA transactions in the very short time remaining to achieve compliance.
Once the industry is operational, the evolution to more elegant approaches
using new and emerging standards and specifications becomes more achievable.
If the work product of this group can specify how to become operational by
April, 2003, **and** provide a vision and path to the future, we'll have
achieved a worthwhile goal. If we look only to the future, the industry will
find a way to become operational without our help.
Thus, while I'm a very strong supporter of looking to the ebXML framework
specifications which include the CPP/CPA, the Message Handling
Specifications, distributed registries and repositories, and the ebXML
architecture which ties it all together, I am not at all confident that all
of this can be brought together in the extremely narrow timeframe required
for the industry to become operational....which is not October, 2003, by the
way -- but April of 2003 as required by ASCA.
Standards Modifications
There are no changes we
can make to the ISA - it's impractical that any requests (other than
qualifier code changes) could move through the glacially slow X12
process in time for it to be useful to us.
We're probably safest in assuming we (WEDi/SNIP ID & Routing) are not
going to be developing any recommendations requiring X12 DM requests nor
other than the most minimal changes to the HIPAA implementation guides.
"...would the current ISA ID values be used to do a lookup in the DNS
table by the VAN/CH to get the proper routing, or will the entire route
be in the ISA?" Only the entity ID (NAIC, DUNS, etc.) would be in the
ISA receiver field. We are advocating no changes to the existing ASC
X12 standards. All proposals assume a lookup for the routing would be
done based on that ID (and its qualifier).
I can't imagine changes would be needed (or possible, given the time
needed for data maintenance to wend its way through the standards
bureaucracy) to the X12N standards in order to support any
recommendations that come out of this sub-working group.
"Are we attempting to introduce new standards based on a transport layer
function (IP)?" New standards, or "recommendations," are a very real
possibility: e.g., a recommendation for exchanging interconnect
information, or Kepa's proposed DNS structure for obtaining routing
information, etc., etc. These would augment the existing X12 standards
and the HIPAA IGs - not replace any parts of them: we have to live with
what's already in place.
EbXML
Of the various specifications coming out of ebXML, the Collaboration
Protocol Profile (CPP) and Registry are the most relevant to our work in
WEDi/SNIP. As reported earlier, Dick Brooks will be working with the
OASIS ebXML CPP/A Technical Committee to ensure the next version of the
CPP spec supports Healthcare's needs - specifically "EDI Addresses" and
links to electronic companion guides.
We also have to have a way to electronically "discover" a Trading
Partner's CPP, and that implies a registry of some sort. Though we have
paid a lot of attention to Kepa's DNS "directory" proposal, prudence
dictates that we at least look at what ebXML has to offer. So I took
the liberty of apprising the OASIS ebXML Registry TC of our interest in
the ebXML Registry for "discovering" Healthcare trading partners' CPPs.
See "Discovery of WEDi/SNIP CPPs," in the Registry listserve at
http://lists.oasis-open.org/archives/regrep/200203/msg00038.html.
It's expected that "hanging" our electronic trading partner profiles
onto the CPP would not be too terribly traumatic to existing healthcare
players: after all, it would not be replacing anything but clumsy paper
documents or web pages. Likewise, a directory (whether Kepa's DNS
"directory" or the ebXML Registry) would give us something we never had
before - an automated means of finding a partner's profile - and make
what had been done manually now automatic, all without upsetting already
in-place systems.
What exists is the ebXML CPP/CPA (Collaboration Protocol Profile and the
Collaboration Protocol Agreement. These specifications were developed over
an 18-month period with active participation from the best minds in the
world. The continued support and maintenance of these ebXML specifications
is now under the auspices of OASIS. The OASIS committee will continue the
work of ebXML on Collaboration Protocol Profiles (CPPs) and Collaboration
Protocol Agreements (CPAs). Development of the ebXML specifications is an
on-going effort sponsored by OASIS and UN/CEFACT. Technical committees for
the ebXML Registry, Messaging, Collaborative Partner, and Implementation are
hosted by OASIS, and Business Process and Core Component work continues at
UN/CEFACT.
A CPP defines one business partner's technical capabilities to engage in
electronic business collaborations with other partners by exchanging
electronic messages. A CPA documents the technical agreement between two (or
more) partners to engage in electronic business collaboration. The committee
will develop enhancements to the existing version 1 specifications that will
result in at least one substantive new version. It will also coordinate its
work with appropriate standards bodies within and outside OASIS. In
addition, the committee will maintain version 1.0 of the ebXML
Collaboration-Protocol Profile and Agreement Specification and will issue
minor updates as needed.
All of the ebXML specifications are publicly available in electronic form at
no cost to interested parties.
Thus, one of your proposed "requirements" could be stated as follows:
"The EDI Addressing specification for health care must enable the automation
of the trading partner setup process."
This requirement could then be satisifed by stating:
"The automation of the trading partner setup will be accomplished according
to the specifications and rules set forth in the ebXML Collaboration
Protocol Profile and the Collaboration Protocol Agreement specifications.
These specifications are available from OASIS at
http://www.oasis-open.org/committees/ebxml-cppa/."
Just to give everyone an idea of which companies are involved in the
continued support and development of the ebXML CPP/CPA specifications,
here's a current list of members of the OASIS Technical Committee. As you
can see, many of the world's leading ISV's are actively involved in this
work effort.
Liaisons
NCPDP Lynne Gilbertson lgilbertson@ncpdp.org
NIST Lisa Carnahan
OASIS ebXML Collaboration Protocol Profile and Agreement TC. The chair, Dale Moberg
Identifiers
Actually, in the WEDi/SNIP ID & Routing group, we're merely concerned
with the manner in which entities are identified in the ISA interchange
header (and perhaps the GS) segment for routing. As Rachel said
yesterday, "the focus [of our group is] on the 'functional use' of the
identifier in the ISA as the key to discovering the detailed EDI
addressing information." Sometimes we do talk about the problems with
the lack of standard identifiers (especially for providers) in the
application transaction sets, but it's not in our charter to solve that
big, hairy problem!
Background
RosettaNet and other initiatives have chosen to identify every partner
using the same ID domain, such as D-U-N-S. This does make things
slightly simpler, in that no one has to remember what kind of identifier
this 9 digit number is - it's always a D-U-N-S!
I don't really think it's necessary, though, to force all players to
identify themselves using IDs from the same domain. Christopher J.
Feahr, OD, may prefer to always identify himself with his Federal Tax
ID - it's incumbent then for all his partners (payers and lens
manufacturers) to address him with his TIN in the ISA. But, another
provider, like Children's Hospital, may choose to use its HIN (Health
Industry Number) for procurement transactions, but the D-U-N-S when
exchanging administrative HIPAA standard transactions with payers. On
the other hand, insurance companies might choose to be identified with
their NAIC company codes.
Most entities have at least one ID from multiple domains - e.g.,
Christopher J. Feahr, OD most certainly has both a D-U-N-S and a TIN.
Aetna has not only a D-U-N-S and a TIN, but also a NAIC company code.
Some outfits even have more than one ID from the same domain - it's easy
to have multiple D-U-N-S numbers due to mergers or acquisitions. Even
though the Federal Tax ID number doesn't have the same weaknesses as the
Socialist Security number used for individuals - it's almost never used
for authentication, but only for identification - some entities still
may prefer not to use it to identify themselves, leaving them to favor,
say, the D-U-N-S.
Since an exchange of HIPAA standard transactions is initiated by the
provider, it's easy enough for the provider to obtain the payer's EDI
ID; for example, the NAIC company code of the payer could appear
directly on the patient's insurance card as the "electronic" EDI address
for inquiries and claims. From there, it's clear sailing to locate the
payer's CPP based on the NAIC.
But as I ruminated on Tuesday, in "More Stuff and Questions on Routing
Identifiers," how would the payer know how to address the provider it's
responding to? There doesn't seem to be any clear way in the 837 or 270
for the provider to tell the payer which ID and domain to use for
addressing transactions back to him. Always using the TIN for ISA IDs
might solve this problem, but forcing an inflexible naming system on all
partners ("You must always use the TIN") might be less desirable than
figuring out some way for the 837 or 270 to communicate the preferred
EDI ID (and domain) for responses.
I'll make one concession, though: mandating use of a single domain
(e.g., the TIN or D-U-N-S) to identify all parties (e.g., providers,
payers, repricers, TPAs, CHs) on the ISA would be far preferable to the
situation we have today with a surfeit of payer-assigned provider IDs.
Aside from that, obtaining a DUNS for your own organization is free: I
didn't pay anything to get assigned a DUNS from D & B, and as I
explained to Chris Feahr this morning, he can get his DUNS for free by
following the procedure I outlined. I think you have to pay $.75 or
some other nominal charge to get the DUNS numbers of other organizations
(though I, too, have gotten those free when I said the numbers were for
"research" - I never pay retail).
In any event, you would rarely have to ask Dun & Bradstreet for the DUNS
of your trading partner; more often is the case your trading partner
would give you his DUNS, telling you that's how he is addressed in the
ISA. Everyone knows his own DUNS or Federal Tax ID (by the way, the
Federal Tax ID is the same thing as the Federal Employer Identification
Number - EIN or FEIN) - which is "shorthand" for saying someone at his
own organization (say, the CFO) certainly knows these IDs.
Once you have a DUNS, enumerating the DUNS+4 is free
The National Provider ID (NPI) registrar will certainly not be assigning
IDs to providers based on "contract" number, so it's clear that payers
will already have to be working on separating the notion of contract
from that of provider ID in their HIPAA remediation efforts. So whether
payers used the NPI, D-U-N-S, DUNS+4, HIN, or Federal Tax ID to identify
providers, assignment of these IDs will necessarily be based on licensed
entity, individual, location or role - but never on the contract with
the particular payer.
Nonetheless, even though we're sometimes forced to discuss the general
notion of IDs as used in the application transaction sets, our primary
problem to solve is getting some consistent way of identifying providers
as EDI participants - and getting everyone (including payers) to use
that same ID for looking up providers' EDI addresses (inter alia) in the
Healthcare registry. It will be a great step forward if our small group
gets all players singing from the same hymnal as far as ISA
identification goes; it would be icing on the cake, indeed, if interim
application solutions to the lack of an NPI came out of our group, too!
It sounds like we're coming to some sort of agreement that not only
providers, but payers, too, find it cumbersome to deal with proprietary
payer-assigned IDs as EDI Identifiers on the ISA. Are we getting closer
to being able to make some definitive statement whereby we recommend
that all providers' (or their agents') EDI portals be identified by
DUNS, DUNS+4, HIN or Tax ID (the only current relevant choices in the
Interchange ID Qualifier)?
Working with real examples helps in two ways: (1) it holds one's
attention better to use real examples, instead of saying D-U-N-S xxxx
for Hospital Y, and (2) if you have real good luck finding, say, a
D-U-N-S for every practice and hospital you may have ever been
interested in or heard about, perhaps it means D-U-N-S has great
coverage and we could constrain the routing ID for providers to always
be a D-U-N-S for consistency and simplicity. This is what RosettaNet
and GISB have done: all trading partners must be identified with their
D-U-N-S.
Some examples follow, with nothing changed to protect the innocent. The
punctuation typically used to make the printed ID more readable consisting of dashes in the D-U-N-S and the FEIN - would not be present
in EDI or our registry.
D-U-N-S:
04-643-0013 - CHILDREN'S HOSPITAL, COLUMBUS , OH
07-164-3589 - RIVERSIDE METHODIST HOSPITAL,COLUMBUS , OH
Federal Tax IDs (FEINS):
23-2229683 - Aetna Inc.
61-0647538 - HUMANA INC.
95-4505291 - UCLA Orthopaedic Surgery Medical Group
NAIC:
68241 - Prudential
60054 - Aetna
54771 - Highmark
HCFA Carrier (Medicare)
16360 - Nationwide - Ohio
00880 - SOUTH CAROLINA BC/BS
The HIN (Health Industry Number) is kind of tricky to locate. I called
HIBCC, the registrar for the HIN, and they wanted $10 for each ID!!! even though I told them they were just for some examples in a paper.
You would have thought they would have been grateful I wanted to mention
them at all! I would prefer HIN examples for hospitals, clinics and
other providers, so I would appreciate if someone on this list would
supply me some. In actuality, if the HIN were going to be used as a
routing identifier, the party identifying itself with a HIN would
probably know what its own ID was. Here are some examples for the HIN:
52F8TXK00 - BAXTER HEALTHCARE
I8IVONE00 - CARDINAL HEALTH INC.
43KEC3K00 - HUMANA HEALTHCHICAGO
I noticed that the 835 guide does not have the ABA Routing Identifier
listed as one of the permissible codes for the Interchange ID Qualifier
in the ISA. Wouldn't the ABA Routing Identifier typically be used as
the receiver ID for payment orders (835) to banks? Can you even route a
payment order through a clearinghouse (or VAN) to a bank, or do you
always have to "hook" up with your bank directly? Clearly, the 835 EOB containing PHI - should go between the payer and the provider directly,
or through a CE like a clearinghouse. Are there even any Value-Added
Banks that can handle PHI?
ABA Routing Codes for Banks:
071000013 - BANK ONE, NA, CHICAGO
021000018 - The Bank Of New York
We are attempting to develop recommendations to the Healthcare industry
for Trading partner identification and transaction routing. In order
to fulfill the spirit of the HIPAA law, it must be possible for entities
willing to use the standard transactions to have a somewhat predictable
(read: standardized) means of getting their standard transactions to the
payers.
Everyone knows their own name(s). I even know my own D-U-N-S and FEIN.
Providers probably know theirs, in addition to their HIN, and eventually
their NPI. Payers know theirs, which might include their NAIC. My
D-U-N-S should be the same, regardless which intermediaries I choose to
use. A payer's NAIC, if he prefers to use it, should be the same
regardless of the intermediaries the provider uses. Since these IDs
have already been assigned, and are globally unique within their
respective domains, why not use them? - at least until the globally
unique National Payer and Plan IDs are available. And by all means, the
"ZZ" should be banished: there should be no "mutually defined" in
standards!
IDs can't be used for authentication: there's nothing secret about
them. You can easily find my D-U-N-S, even if I didn't give it to you.
And I can easily find out what your NAIC is, even if you didn't give it
to me. Likewise with HINs and eventually, National Payer and Plan IDs.
Since IDs are easy to discover (even lacking a central database), they
make ideal EDI addresses - but lousy passwords! Actually you shouldn't
even have to "discover" them - the provider should be able to find them
on the back of the patient's insurance card. Given the payer's ID, it
should be possible for a provider, who's willing to cobble together a
standard transaction, to get it on its way to the payer in the least
confusing way possible. Anything less might be construed as a roadblock
in the way of Administrative Simplification.
You admit that you "...have a very non-standard situation in the ISA at
this time, with the possibility of providers needing to identify
themselves in different ways to each receiver." Standards are needed
only for interoperability. Undoubtedly, your clearinghouse service is
a well-oiled machine which works well for your customers, who are
already seamlessly engaged in Healthcare electronic commerce. It
probably matters little what we come up with here - your paying
providers and payers are already electronically enabled, and they will
happily accommodate themselves to whatever idiosyncrasies you mandate
for the ISA.
But to require a provider new to electronic transactions to munge the
ISA, using IDs other than the sender's and receiver's own, might be
construed as adversely affecting the provider as surely as charging fees
for the privilege of submitting a claim or eligibility request. Once
this door is opened, then payers might very well use other tactics like
requiring the submission of standard transactions on diskette, or
enforcing weird or obsolete protocols like X.400 or BiSynch, if the
(payer's) preferred VAN or Clearinghouse is not contracted with.
Proprietary IDs
Marcallee Jackson told us "[e]ach healthcare clearinghouse maintains a
list of payer ID's. These ID's are sometimes designated by the
clearinghouse, sometimes by the clearinghouse's trading partner and
sometimes by the payer. I believe its this code that is commonly sent
in the ISA field."
Isn't our problem made easier if the payer tells everyone what its own
name or ID is, constrained by the allowable qualifiers in the ISA
Interchange ID Qualifier? In the absence of the National Plan ID, we
should allow for a payer being identified whatever ID it prefers Anthem might prefer the D-U-N-S and Highmark the NAIC. Some payers
might have two or more D-U-N-S, any of which may be acceptable.
Likewise, some providers will identify themselves by the HIN, others by
the FEIN.
But it does no service to interoperability if a provider, using HIPAA
standard transactions, has to make a determination like "Payer 'A' is on
CH 'B', who demands that the payer be identified by 'C' in the ISA,
except on Thursday, when it must be 'D'." Along the same lines, do we
want to banish use of the "ZZ" (Mutually Defined) qualifier, which - as
Kepa has pointed out - is often used to specify an ID given to the
provider by the receiving payer?
At the front of my mind always is the mess we have now with
payer-assigned provider IDs. This is probably why I slipped and said
"[our] primary problem to solve is getting some consistent way of
identifying *providers* as EDI participants.." Indeed, we want
consistent ways to identify all participants, including payers,
Clearinghouses, Third Party Administrators, Re-pricers *and* Providers.
It should be clear from all my monologue over the last two or so months
that I understand we have to identify all players in order to access
CPPs in a Registry and address parties in the ISA.
But as it is, there doesn't seem to be much argument over how payers are
identified: the NAIC seems to be relatively well standardized upon, and
for our purposes it's a perfect identifier. You don't see providers
assigning proprietary provider-assigned payer IDs - instead we have a
common sensible and standard means of identifying payers (e.g., the NAIC
company code).
The big problem to solve, as I have oft-repeated, is to level the
playing field and have the payers extend the same courtesy to providers:
address them by their own "name," rather than forcing providers to
"memorize" a bunch of payer-assigned proprietary IDs (whether for the
ISA or within the application transaction).
I can't speak for the other payors, but our Plan has been eager to see a
national provider ID for some time now.
We use multiple proprietary IDs and have wanted to consolidate onto one
new number -- we even had a project to modify the provider ID fields in
all of our systems. Unfortunately, the proposed National Provider ID has
us afraid to re-enumerate providers on our own as we are sure the final
Reg will come out the day after we are done, making us do it all over
again. ;-)
But seriously, multiple IDs is as much of a problem at our end as it is
at the provider end.
As for whether there is intelligence in the numbers, the answer is no
and yes. The no is because there is no intelligence in the number
itself. Rather the number is the intelligence. For example, if a
provider has multiple locations, he or she will receive multiple ID
numbers with each number corresponding to a location on our system.
Because we started up new products in the mid-90's and took over an HMO
at the same time, some providers received different ID numbers for
different products. This is because those products or companies were
supported on different systems than our traditional BCBS business, and
those systems had different requirements for ID numbers.
Regarding the information we will require on a claim, we will follow the
same process as described by Doug Renshaw, except that we will not modify
the NAIC numbers.
NPI and National Plan ID
I agree that the lack of standard Provider IDs is a problem. However, if
the suggestion is that the industry ought to embrace the DUNS number (or any
other number) as an unofficial standard, then I would object to that
concept. The problem with that idea is that the release of the final NPI
regulation is hanging over us.
Enumerating providers is not an easy thing to do. The communication of the
new numbers and the process for doing this is time consuming and costly in
terms of time, money, and resources. There is significant work involved in
creating new provider tables/databases, loading this information, and making
sure that all systems process this information correctly. Finally, there
will undoubtedly be claim processing problems as an entity migrates from one
number to the next.
If the industry (or parts) were to move to DUNS and HHS releases an NPI
regulation which uses anything other than DUNS (which it is expected they
will do), the industry will have to discard all the work to move to DUNS and
re-duplicate the effort. There would be no way for the industry to
recapture the lost time, effort, and money that it spent moving from today's
proprietary IDs to the NPI.
The companies I work for have been poised to move to new provider IDs for a
number of years now and have been unwilling to pull the trigger for fear
that immediately after we do so the HHS reg will come out and the whole
thing will be wasted. I would not be surprised if the same is true with
other carriers. The best thing for all concerned is for HHS to release the
NPI reg and for providers to act quickly in getting their new ID numbers.
(Keep in mind that the move to a standard could break down if Providers
don't hold up their end by getting these numbers.)
The same is true with standard group IDs and payer IDs, for what it is
worth.
Application
This seems like an overly broad mission, especially since we're mostly
concerned with interoperable guidelines for "discovering" EDI addresses
to use in the routing of standard EDI transactions. Reading the
Identifiers subgroup's scope, I'm not surprised people would think we're
going to get into the nitty grittty of using identifiers for providers,
payers and contracts within application transaction sets! I have no
objection to looking at this interesting problem or writing it up in our
white paper (which would consist of just copying and pasting from Kepa's
Identifier myths), but this is really a topic better served by the
overall WEDi/SNIP Business Issues SWG.
Identifiers are of interest to us here in the WEDi/SNIP ID & Routing
group only insofar as they're used to assist in the routing of standard
transactions - i.e., when they're used in the ISA receiver field. The
MPD only affects identification of the provider (and the contract) in
the claims ensconced within the X12 transaction.
do think we will have to at least pay lip service to aspects of
identifiers as they're used in the application transaction set - if only
because applications will have to divine an ISA receiver ID from
something, and that something will be the various combinations of IDs
used today (within the application or the 837, say). For example, to do
routing, a payer might need some way to find the provider's DUNS, HIN or
EIN - one of the ID domains allowed by the HIPAA IGs in the ISA. We
can't say you can key on any combination of criteria (including plans,
contracts and line of business) to search for a (payer's) EDI address: a
VAN or EDIINT software, which don't burrow into the application
transaction, wouldn't have anything but the ISA receiver ID (and
possibly some stuff at the GS) for making routing decisions. So keys
used (as nodes) in Kepa's DNS "directory" would necessarily be
restricted to ISA and GS information.
my provider's application's programming
problem to determine which identifier is used on the claim or eligibility or
cert request. For all of them (many numbers for a single provider), and in
my case, many providers, I'll still have a single EDI address (well,
actually 4 - 2 for batch and 2 for near-real-time).
I guess the real question is how the endpoint responder gets my EDI address.
What they get in the transaction will be the unique provider identifier they
have told me to use. If my common EDI address is not in the message for them
to generate a response to me, then they would have to discover it which
means I'd have to register all provider identifiers pointing to one of the 4
EDI addresses (now there's a really ugly thought...). I guess that's why I
thought the ISA address would be my ultimate response address, but if that's
not the case.......
Since Loop 1000 shouldn't be used as an "audit" trail - and, indeed, it
can't because nobody along the way can *add* instances of the loop
(because 1000A and 1000B both have a loop repeat of 1 in the HIPAA IG) they can only change Submitter or Receiver - then it seems like it is an
application transaction representation of the two parties identified on
the ISA: the sender (submitter) and the receiver.
I can see how you would think "...that a 'repricer' would leave loop
1000 information on the repriced claim exactly the same as when he
received it," but since the re-pricer opens the envelope and potentially
changes stuff, I think we have a whole new "round" of sender and
receiver.
In Raj's first example, when the provider (or his BA) formats and sends
an 837 to Raj (the re-pricer), the provider or billing agent is the
submitter or sender (in both Loop ID-1000A and the ISA), and Raj said he
is the receiver (in both Loop ID-1000B and the ISA).
When Raj "re-prices" the claim, I agree with his intuition that he is no
longer the "receiver," and he must change the loop somehow. I'd say he
becomes the submitter (loop ID-1000A) and the payer should become the
receiver. Because Raj is now the submitter, his name and telephone
number can now appear in the 1000A PER segment, so the receiver can have
a real person to talk to find out what the heck is going on!
don't think the 1000A (Submitter Name) and 1000B (Receiver Name)
"audit trail" in the 837 are all that important. Besides, the other
transactions (like the 270/271, 276/277 and 835) don't have an analog of
this "audit trail." Based on previous observations, though, it's
probably the usual case that the 1000A and 1000B Electronic Transmitter
Identification Numbers exactly reflect the sender and receiver IDs on
the enclosing interchange envelope.
The ISA is incapable of carrying application data - unless you can
manage to squeeze it into a ZZ-qualified sender or receiver ID! The ISA
sender and receiver IDs must be valid identifiers from a limited set of
domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet D-U-N-S,
IRS Tax ID (FEIN), etc. IDs of this sort can serve as both routing
identifiers *and* application identifiers. Therefore, it's entirely
possible that any of these also appear in the "application" NM1s (e.g.,
the 837's 2000A loop to identify the billing provider).
Generally, you would use one of the NM1 "application" identifiers (say,
the Tax ID) for a provider to locate his CPP (Electronic Partner
Profile). The CPP would then tell you what identifier to use in the ISA
for the receiver. It would be mere serendipity if it turned out to be
the same (the Tax ID in this case) - it could just as well be the
D-U-N-S or HIN of the provider.
As pointed out by various folks, including Jan Root and Bob Poiesz , the
1000A (Submitter Name) and 1000B (Receiver Name) "audit trail" are of
limited usefulness - they most likely just reflect what's on the ISA.
And the ISA sender ID is used solely for reporting TA1 and 997
acknowledgements.
Determining the ISA receiver of an interchange containing application
transaction turnarounds depends on identifiers supplied for the billing
provider (in the case of the 837) or information receiver (270 or 276).
For example, at least one of the IDs supplied in the 837's 2000A loop to
identify the billing provider would be used to locate the CPP
(Electronic Partner Profile) for that provider.
Depending on attributes of the desired exchange (e.g., functional group
of the response, say the 277U), the CPP may provide DeliveryChannels
("EDI Addresses") describing the portal to which the interchange is
sent, along with the desired receiver ID to be inserted into the ISA.
This ISA receiver ID may very well be different from that of the sender
ID on the interchange containing the original 837!
Knowing what your own "name" is begs the question whether your trading
partner can divine the ID you're known by. Imagine the scenario where a
physician first encounters a patient. Let's assume Peter Barry's
grandiose plans for insurance cards with National Plan IDs comes to
fruition: the National Plan ID could be used to search the "National
Plan ID database" to come up with, say, the NAIC company code of the
payer. From there, the WEDI/SNIP Registry would be searched on the NAIC
to come up with the WEDI/SNIP CPP (Electronic Trading Partner Profile)
which is used to tell you how to deliver eligibility inquiries and
claims to the payer handling the particular plan. Until the advent of
the National Plan ID, I suppose the NAIC company code of the payer could
appear directly on the insurance card as the "electronic" EDI address
for inquiries and claims.
But I don't see any way for the provider to use the 270 Loop 2100B
(Information Receiver Name) to convey his D-U-N-S to the payer for use
in returning the 271 Eligibility Response. If the provider chose to
identify himself by D-U-N-S, how would the payer know which ID to use in
the response's ISA? This might be what Chris Feahr wanted to know,
i.e., how to auto-discover the "return path" back to the provider?
Keep in mind that the provider's sender ID in the ISA should probably be
directly used only for TA1 and 997 acknowledgements; there must be some
other means of figuring out the ID of the provider for application
responses since not only is the ISA long gone (discarded by the
translator), but prudence would dictate that the ID be derived from the
application data (or other data known to the payer) - rather than saving
the ISA sender ID. This may not be a problem for the payer in the case
of in-network providers (where the payer would have the provider's
"preferred" EDI address - the D-U-N-S - on file). But a
non-participating provider has to have some means in the 270 transaction
to give the payer his preferred EDI ID.
The 837 Claim seems to have gone half-way in acknowledging this problem,
and provides a way for the provider (or his agent) to send the
"Electronic Transmitter Identification Number" (ETIN) to the payer in
the 1000A Submitter Name loop. But there's no way to say whether that
code is a D-U-N-S, a Tax ID, or a HIN, or whatever - the 837 IG
unhelpfully says "Established by trading partner agreement." Like the
270, the 837 does have a way for the provider of telling the payer his
FEIN (Tax ID) in the 2010AB Pay-to Provider loop; but even if the
provider used the FEIN as his routing ID, there's no definitive way of
saying that it *is* the EDI ID (as opposed to just one more ID the
provider shares with the payer).
The definitions for Interchange Sender and Receiver seem quite adequate
and appropriate - they say what I've maintained all along. The ISA
Receiver field is only needed to return TA1s and 997s (and possibly 824s
reflecting IG violations). Application acknowledgements, such as the
835 answer to the 837, and the 277 answer to the 276, would not
necessarily be sent to the ISA sender of the original request - instead,
the ISA receiver would be "calculated" based on NM1s in the original
request.
Interchange Envelope
But as it stands, there are only a few ways entities can be identified
in the ISA based on the constraints HIPAA imposes on the ISA Interchange
ID Qualifier. For providers, it leaves us with only the D-U-N-S (and
D-U-N-S with suffix), the Federal Tax ID (or FEIN), or the HIN as
acceptable domains for identifiers - if we rule out the 'ZZ' (Mutually
Defined) qualifier (the ZZ qualifier is usually used for payer-assigned
provider IDs, which are the bane of standardized identification). I
assume that once the NPI is in place, there will be no problem getting
it added as one of the acceptable ID types in the ISA.
X12 is meant to be independent of the transport method. The ISA only
needs to hold "logical" identifiers that represent the sending and
receiving entities - and 15 characters is more than enough for any
conceivable identifier (e.g., DUNS, FEIN, HIN, NAIC, or even the
National Plan ID and National Provider ID).
It was always understood that some sort of mapping table (whether at the
VAN or CH, or in the EDIINT software) would take a logical identifier
and "map" it onto an "EDI Address." An EDI Address would be a
particular mailbox (in the context of a VAN or CH), or the protocol and
addressing specifications in the case of EDIINT or FTP, say. Our
project takes EDI Addresses to an extra level of indirection:
identifiers would be "mapped" to a CPP, which in turn contains one or
more EDI Addresses (selected by preference or functional purpose, e.g.,
"real-time" vs. batch). Each "EDI Address" would describe where
(physical address, e.g., FTP address) and how (packaging, e.g, X12.58
security or EDIINT) to send the interchange.
The logical identifiers used in the ISA are fairly static - how often
does a DUNS, FEIN (or even an NPI, if it comes to pass) change? But EDI
Addresses are ephemeral, subject to the whim of the recipient: one day I
might want claims to go directly to me via FTP, and the next day I might
change my mind and have them go through a Clearinghouse. A dynamic
mapping system keyed on logical identifiers accommodates this nicely.
We probably shouldn't call ISA08 an "EDI Address." It's the recipient's
EDI Identifier. An "EDI Address," as Peter Barry would remind us, is
all the technical mumbo-jumbo that defines the protocols, port addresses
and other desiderata for moving EDI data to a particular point (e.g.,
FTP addresses, dial-up telephone numbers, etc.). The EDI Identifier in
ISA08 will be used to retrieve the recipient's CPP (Electronic Trading
Partner Profile), which in turn will contain the appropriate EDI
addresses.
And yes, it's possible that interchanges can be "going out the door with
identical ISA08 values (identifying the receiver), but be going to
different EDI addresses... because of their specific transaction
payloads." This seems to be a requirement raised in previous
discussions; e.g., "real-time" 270s might be directed to a different EDI
address than "batched" 837 claims. I don't know how this could be done
today with current translators and communication software: how does the
translator convey to the communication software that the interchange is
"real-time" vs. "batch"? If anyone has an idea how they would implement
this with their current systems, please don't hesitate to write in!
If there is no direct link between the translator and communication
software, then the comm software does have to be sensitive to the
payload contained in the interchange - at a minimum it will have to
"drill" into the GS envelope to distinguish eligibility inquiries from
claims, or to examine the GS Application Receiver's Code for hints in
selecting the appropriate EDI address. Likewise, if all interchanges
are sent to a single intermediary, such as a VAN, then the VAN would
have to "drill" into the interchanges (so the correct EDI address can be
determined).
As an example to show why "drilling" down into the GS may be required,
consider the scenarios presented by Doug Renshaw earlier. Highmark might
want interchanges delivered to a different EDI "gateway" depending on
whether "V" (vision claims), "W" (if an institution is in its Western
Region), or "C" (if in its Central Region) is appended to its NAIC in
the GS Application Receiver's Code - these suffixes would determine the
appropriate EDI address to send the interchange to.
If only X12 had adopted ISO 9735 UN/EDIFACT Syntax Version 4 for
interchange control, then we could have avoided the problem of drilling
into the interchange (to retrieve distinguishing information from the
GS). The UNB Interchange Header in EDIFACT not only lets you specify
the recipient identifier (in D.E. 0010 - Interchange recipient
identification), but also an internal routing code (in D.E. 0014 Interchange recipient internal identification), so you can make all your
decisions for routing just by looking at the UNB without going further
in the interchange. See http://www.gefeg.com/jswg/ if you're the least
bit interested in the layout of the ISO 9735 EDIFACT interchange
envelopes. But unfortunately, adopting ISO 9735 interchange envelopes
is not in the cards, so we have to rule out this elegant solution!
As an aside, I'm left wondering how all those translators out there
today are going to handle out-of-network claims from a provider the
payer has never seen before - will they have the capability to
automatically create Trading Partner table entries, dynamically adapting
to new ISA sender IDs as they arrive?
Now, as Rachel would say, I think I'm getting "wrapped around an axle"
with this ISA and GS stuff. After thinking about it, the GS should only
be used for internal routing by the recipient - something we all learned
in EDI 101. No intermediary or communications package should ever have
to "drill" down within an interchange to look at functional group
envelopes.
So we probably only have the ISA available for routing. And if only the
ISA can be used, that probably implies only the 15 character ISA08
Receiver Code is available for discerning EDI addresses - which might
require different recipient IDs for various purposes.
So where does that leave us if a "real-time" 270 has to be sent to a
different "portal" than a "batch" 837? Do we have to use a suffix on
the payer's NAIC company code in the ISA08 receiver field to distinguish
between batch and real-time?
Martin Scholl's impression that the HIPAA IGs allow you to choose the
ISA qualifier "ZZ" so you can put "anything in there" is correct. As
far as I know, the guides have not changed since I last saw them.
And we can accommodate the ZZ qualifier in our CPP Electronic Partner
Profile: the receiver can specify in his DeliveryChannel ("EDI
Address") that the ISA Receiver Interchange ID Qualifier and ID are to
be whatever he deems fit. Perhaps his DeliveryChannel is assigned to
his clearinghouse, and the clearinghouse only knows him by some
*contrived* (CH-assigned) receiver ID using the ZZ "mutually-defined"
qualifier. Since the receiver is a customer of the clearinghouse, he
knows ahead of time what his proprietary CH-assigned receiver ID is, and
can place it in the CPP so senders know what to use in the ISA receiver
field.
Just make sure you understand that the sender would have no way, a
priori, of knowing what proprietary ID to use in the ISA receiver field
until he accessed the receiver's CPP. Remember that no proprietary IDs
could be used to *search* the Healthcare CPP Registry since there would
be no way to ensure their uniqueness across all CPPs for all entities i.e., your notion of ZZ-BILLYJOE might be different from another's
notion of the same pair. That same ambiguity doesn't exist for RA
centrally managed identifier domains, e.g., HIBCC HIN, NAIC Company
Code, Dun & Bradstreet D-U-N-S, IRS Tax ID (FEIN), etc. NAIC Company
Code 54771 is Highmark, regardless who's doing the talking.
Keep in mind that there's no way to compel a sender to identify herself
with a proprietary ID. Given the Open-EDI aspect of HIPAA, a payer may
not even know ahead of time that he's about to receive a transaction
from some provider: how would he ever manage to assign a proprietary
payer-assigned ID to her? On the other hand, if she chooses, a sender
may identify herself with a ZZ qualified sender ID (in actuality, she
may have been forced to by her one and only VAN or clearinghouse).
It doesn't matter that the sender ID is mutually defined: the receiver
never uses the pair except when turning around the TA1 or 997. This
forces me to backtrack a little on what I told Todd Velnosky this
morning: if an interchange using a ZZ-qualified sender field were being
acknowledged, then the TA1 and 997 would have to be returned to the same
clearinghouse the original interchange arrived from, simply because only
that clearinghouse is guaranteed to know how to interpret the ZZ-pair.
To determine the receiver ID of application responses, the sender would
use one of the NM1 "application" identifiers (say, the Tax ID) to locate
his partner's CPP, which in turn (using the DeliveryChannel) says how to
get the response where it's going and what to stuff in the ISA receiver
field.
Didn't I say the ZZ-qualified proprietary ID would not be a problem?
i.e., once the CPP was found, the EDI Address would inform the sender
that the ISA receiver was to be a ZZ-qualified proprietary ID. I just
wanted to make sure we all understand that the sender would have no way,
a priori, of knowing what proprietary ID to use in the ISA receiver
field until he accessed the receiver's CPP.
But a "mutually defined" ID is not necessarily unique (except within the
domain comprised by a particular payer or CH), you have no idea who
assigned it (just by looking at the ISA), and it cannot be used in a
National Healthcare directory. It has a meaning only in the context of
a particular payer or Clearinghouse. And if it's particular or
peculiar, it has no place, really, in our recommendations. I see no way
around this conundrum.
You may recall that we had submitted definitions for ISA sender and ISA
receiver that I thought were considered acceptable. The basic concept
is that the sender is the entity responsible for creating the exchange
and it's contents and the receiver is responsible to processing the
contents of the exchange. So, if the contents of the entire exchange
(ISA to IEA) will be processed entirely by the receiver, then yes the
ISA receiver will most likely be the provider or payor.
if I understand this thread, we MUST choose one of the legal ISA
identifiers as a KEY to this (yet-to-be-defined) record that explains all
of the 'collaboration" details... including other ISA identifiers that
might be acceptable?
If so, I would vote for the Fed. Tax ID# for the registry key. As I look
down this list, the FTIN seems to be the only one reliably there 100% of
the time and one that virtually every business will know (about itself) and
have no qualms (and violate no user agreements) disclosing to "the world".
-Chris
01 Duns (Dun & Bradstreet)
14 Duns Plus Suffix
20 Health Industry Number (HIN)
27 Carrier Identification Number as assigned by Health Care Financing
Administration (HCFA)
28 Fiscal Intermediary Identification Number as assigned by Health Care
Financing Administration (HCFA)
29 Medicare Provider and Supplier Identification Number as assigned by
Health Care Financing Administration (HCFA)
30 U.S. Federal Tax Identification Number
33 National Association of Insurance Commissioners Company Code (NAIC)
ZZ Mutually Defined
In the absence of the national identifiers, we are left to select from one
of these coding systems or to use the ZZ Mutually Defined. It's my opinion
that if the objective is to be able to use the identifier from the ISA to
discover more detailed EDI addressing information, then it's irrelevant
which coding system the ISA identifiers are based on. The only requirement
at the present time is that to be compliant with the HIPAA specifications,
one must choose one of the above.
Thus, I'm not sure that I understand the detailed discussion of various
identifiers and identification systems. Wouldn't it be more on point to be
examining how the ISA identifier would/could/should be used to link to the
EDI Addressing information?
Furthermore, when (notice that I'm the eternal optimist and didn't say if)
the national identifiers are finalized, then I would certainly expect that
the ZZ Mutually Defined option would go away....and even perhaps the other
choices in favor of the national identifiers. Thus, I again reiterate that I
think it's quite irrelevant to the goal of this work group to get too
wrapped around the axle about various identification systems. Rather,
shouldn't the focus be on the "functional use" of the identifier in the ISA
as the key to discovering the detailed EDI addressing information?
Doug Renshaw was kind enough to respond to my pleas from 15 March for
information on how folks currently (or will) handle the ISA and GS for
routing standard transactions; he has graciously agreed to let me pass
on Highmark's plans as grist for discussion. Other than Doug, only Tim
Collins and John Bristor have responded. Tim divulged some information
on how Kentucky Medicaid might be handling IDs, and John Bristor shared
what appears to be some kind of Medicaid EOB with strange and wondrous
proprietary IDs. At this rate, I don't have too much to work from: I
hate to nag, but with the hundreds of people on this list, surely some
more folks could throw information my way so Ron Bowron and I can do a
"proper" requirements analysis.
Doug said that Highmark will require that its NAIC code (54771) be
submitted as the Receiver ID in the ISA. In the GS, he will require the
NAIC of the payer that the transaction applies to, which could be that
of Highmark or several other associated payers. NAIC codes are 5
characters, and the GS receiver ID can have a payer-defined 3 character
suffix applied to the NAIC. In some cases, they will use a
Highmark-assigned alpha suffix to manage internal routing requirements
of stuff within the same payer.
For the Sender ID in both the ISA and GS, Highmark requires the use of a
proprietary trading partner ID. For transactions coming from a
Clearinghouse, they'll have a trading partner ID for the clearinghouse
which will be tied to individual providers.
Also, Highmark requires a logon and password to connect to its network
for sending and receiving EDI files. Highmark is considering use of the
Internet to replace its dial-in network, but use of a logon and password
would still be required.
Highmark will only accept standard transactions, and only for a set list
of payers who are in the Highmark "family". If a provider attempts to
send transactions to payers not on Highmark's list, they will be
rejected. Highmark is not attempting to offer providers a "portal" for
submission of their claims to any and all payers - only a means of
getting claims directly to itself and several of its subsidiaries. Doug
does agree with my belief (by reading the NPRM) that payers will have to
offer providers a direct "portal," or else will have to contract with a
clearinghouse to collect standard transactions for them.
As for Highmark's use of NAIC suffixes in the GS, they spell out some
specific uses for particular transactions as required for internal
routing and processing purposes. Specifically, Highmark will require a
"V" on vision claims, and for institutional claims, they will require a
"W" if the institution is in its Western Region and a "C" if in its
Central Region. Doug recognizes that NAIC codes are not a solution
that works for all health plans, and that Highmark may need to change
its requirements if and when a national plan ID is established.
Likewise, according to Tim Collins, Kentucky Medicaid now has plans to
re-assign proprietary provider IDs in anticipation of HIPAA . These IDs
are "intelligent," in that the 10-digit number used on the ISA denotes
the type of submitter (e.g., Medical Practice, Software Vendor or
Billing agent), further qualified by the type of institution on whose
behalf the transaction is being submitted (e.g., Hospital, clinic,
pharmacy, dental, etc.).
Doug Renshaw didn't go into detail on how Highmark's provider IDs are
generated, or whether they are "intelligent" or not. I guess that
doesn't matter. What I do know now from these few "scenarios" including the Medicaid sample from John Bristor - is that payers sure do
like proprietary provider IDs! But do providers feel the same way?
If anybody were thinking we would come up with a scheme whereby you
could put a plan ID into an ISA (which you can't, because the
Interchange ID Qualifier can only address carriers or entities
addressable by the DUNS or EIN), and auto-magically the interchange
would end up at the appropriate place (the repricer for claims, or the
Third Party Administrator for eligibility requests), then (1) that would
be neat, and more importantly (2) it would be really, really hard to do.
I think if you want to have an 837 go to a particular repricer, you're
probably going to have to explicitly put the repricer's identifier (what
is that? - a DUNS, an EIN?) in the ISA receiver field. And, likewise,
if you want a 270 to end up at a particular Third Party Administrator,
I suppose that TPA's identifier will have to appear in the ISA receiver
field. How is this done today using X12 through Clearinghouses? what's expected in the ISA (and perhaps the GS)?
See "EDI Meets the Internet: Frequently Asked Questions about Electronic
Data Interchange (EDI) on the Internet," RFC 1865 at
http://www.ietf.org/rfc/rfc1865.txt, especially sections 5.8. Can the
ISA 06 or 08 identify any entity other than the 'end' Trading Partners
(i.e. a routing entity)?, and 5.10. Are there other options for routing
EDI X12 messages?
...although the ISA06 and ISA08 elements are supposed to be
used to identify the sender and receiver of the interchange,
the receiver of the interchange could be a clearinghouse
(as well as a VAN) that processes the interchange and then
forwards the data to the ultimate recipient. In this case,
you could put the receiver ID of the clearinghouse into the
ISA08. The clearinghouse would probably have to determine the
ultimate recipient of the message by looking inside the
transaction set (or perhaps by using the GS03).
Though this IETF RFC is obviously not a HIPAA document, it proves as of
1996 that this was not a weird practice. The TA1 and 997 go back to the
sender in the ISA, whether a CH, billing service or the "real" provider.
What's the problem with calling the CH who builds the ISA the "sender"
or "submitter" in order to differentiate him from the "providers" he's
aggregating? If the provider (or his agent) puts the provider's ID in
ISA06, then the provider is also the sender (or submitter).
Analogously, the "receiver" could be a CH or payer. A payer is always a
payer, and even sometimes the "receiver" in the ISA.
The Present
1.
The present is payer-centric. It could keep going that way, but the
future health care electronic traffic will include provider-to-provider
transactions involving delivery-of-care and reduction of medical errors (4th
largest cause of death and injury). Having every provider set up in advance
with every possible other provider is not very practical. In the future,
eventually, providers will participate, not as clients, but as equal
participants. Especially, a sender will be able to send an asynchronous
message and the provider will be able to receive it. This is a hugely
significant change from the payer-mailbox model now used for batch
transactions and the client/server model now used for DDE transactions
The note includes "distributed my EDI documentation". That would appear
to include two types of information: (i) connectivity attributes, which are
the primary subject of the CPP suggesting there might be a more efficient way
to let provider computers know the terms for connectivity, and (ii)
transaction requirement profiles, the subject of "companion guides", which
might become electronic profiles, the "7-level" edit subjects. If these
subjects cannot eventually be reduced to computer-readable information, we
will have lost a lot in the goals of standardization.
The dominant business model in health care is:
1. For the most part, only health care claims are submitted electronically
by providers to the party they've determined is the financially responsible
party for reimbursement.
2. The format used for electronic claims is most often the NSF batch file
format, or some variant thereof.
3. It's not typical that a provider submits claims directly to the
financially responsible party. Rather, intermediaries are more likely than
not to be in the picture. Intermediaries can be clearinghouses, TPAs,
repricers, billing services, and so on.
4. These intermediaries typically determine the financially responsible
party by interrogating data contained with the batch file.
5. While the NSF batch file has batch header and trailer records which
start/end the batch, the records in the batch are fixed field/fixed record
multiple record types.
6. The industry does not use the typical EDI VAN store and forward model.
Thus, it has not built an infrastructure that uses an identifier from a
batch header record to "mailbox" files for the receiver.
7. The industry model is one of the provider always have to "push"
electronic claims to the financially responsible party through an
intermediary and to then "pull" any return messages.
8. Other types of information exchanges, queries, referral requests, etc.,
are most often performed via phone, IVR, DDE, or fax. Thus, today's
application systems do not typically support nor enable batch file transfers
for these types of information exchanges.
As you know, the model which most other industries use for standards-based
EDI exchanges is one where the receiver of the interchange maintains a
mailbox at some "post office" - most often called a VAN. Thus, both parties
to the information exchange maintain their own mailboxes (or multiple
mailboxes) at a post office(s) of their choosing. It's this model that the
current X12 control structures enable and support.
Providers' Perspective
Noticed that I never answered your questions below, so I thought I'd take a
minute & do so. When everything was fee-for-service, the world was simple then HCFA decided to contract for certain services from certain providers,
and to only pay "schedule" rates for other services. The flood gates are now
wide open, and we have nearly as many health plans as we do employers
represented in our databases. The carriers offer "specialized" plans and
there are no guidelines on how these coverage agreements are structured its truly a boutique business. The carriers sell the plans to employers,
who turn around and offer the coverage to their employees - larger employers
offer several different coverages, depending on the employee's needs. They
(carriers, large self-insured employers, HMOs) then come to our front door
(some thru the back door) and negotiate with us to be a contracted provider
to perform some or all of the services they are selling at the other end.
Along with these plans came another cottage industry - third party
administrators (TPAs) - who sell their services to employers and carriers -
they contract to perform lots of different services including claims review,
claims repricing (taking the provider's charges and "re-pricing" them to
reflect contract agreed charges), eligibility & benefits checking, etc.
Further, if the plan is capitated, they perform other services related to
lifetime benefits and adjudication on behalf of the plans. There are
numerous situations where more than one TPA can be in the mix - e.g. a
professional repricer before the plan administrator, and even a separate
reviewer. They can be in any sequence, though the repricer is usually the
first stop for claims if one is present. The only good news is that usually
(but not always) the TPAs can figure out amongst themselves where to send
the claim next in the sequence because they only deal with a limited set of
contracts.
The kicker is that these "third parties" usually get inserted into the mix
because neither the employer nor carrier want to be burdened with figuring
out the nuances of the ridiculous contracts they are negotiating. So they
contract with the third party, and then tell us that "for plan INS-xxxx,
send the claim to RPCyyy, and request eligibility & benefits from TPAzzz".
So, it ends up being our problem to determine where to send claims and
address inquiries. I have no doubt that this situation will continue with
EDI, so having a separate set of addresses by plan and transaction makes a
lot of sense to me. This assignment is somewhat dynamic, however, and needs
to be kept up to date by whoever is contracting for the coverage. These
contracts are usually not long-term, and when they change, often the claim
destination can change along with other contract terms. I'm still not sure I
understand how we would ever go about determination that re-discovery is
necessary, but i'm learning more every day...
Hope this helps to explain some of it.
One of your clients visits Iowa (vacation hotspot that it is)...a place
you don't have a large presence. He is injured and end up at one of my
hospitals. We don't have a trading partner agreement with you, as we
have no prior relationship. We can't send you an automated eligibility
inquiry, as we don't have your routing #. Do we have to train our
registration staff to call and ask for routing #? What do we do to get
the electronic process going? Or do we have to program our system to
automatically drop to paper when the claim is processed? (totally
shoots the standardization process.....)
Youbetcha! If/when the NPID becomes real, and when payers all agree to apply
for and get one, and then when they all agree to put the identifiers on the
cards, we'll all be very happy. Ditto the Nat'l provider IDs for inclusion
in the ISAs (are providers even required to apply for them?). Until then,
however, we'll unfortunately have to live with a hodge-podge of identifiers,
but that shouldn't keep us from making any forward progress.
What if we simply said, for example: ok, all you payers that want to post
your CPPs to begin development of CPAs with potential provider trading
partners, post in the DNS the address where your CPP can be found under
whatever identifier you are currently using on your insurance cards preferably your group/plan ID, but if that's not present, and all you have
is a phone number, post it under that. Without waiting for a national
identifier, and waiting for the hundreds of millions of insurance cards to
be re-issued, we can just start moving forward with establishing CPAs, and
sending 837s. If I could just convince 25 large carriers to do that, I
could achieve 50% of my goal for development of TPAs by 4/16/03, with only a
fraction of the work. If the payers want to designate a CH to be their
receiver, then they can simply point their identifier to where the CH's CPP
resides (all the same to me).
If this is true, and we want to eliminate the burden on the intermediate
hops (CHs, VANs & whatnot) in not having to delve into the message to try to
determine who the recipient should be, the only option left is to place the
endpoint receiver into ISA08. Since that is effectively the envelop within
which I'm sending the claims, I therefor can't place claims for other
destinations into it (I suspect that Aetna wouldn't want to sort thru
primaries to determine which were for them, and then forward the rest to
their intended destinations...).
Realistically, this means that if I were to send claims for 50 different
endpoints to a CH, I would send them 50 different ISA/IEA batches, some of
which may only contain 1 or 2 claims. If the CH is performing routing for
me, then they would probably have the CPAs already established with the
endpoint receivers (the CHs would already know how & where to send the EDI
packages without opening them). If the CH is a designated receiver for an
endpoint, then they will have Trading Partner Agreements which tell them
where/how to route the claims. In either event, routing should be easily
accomplished without having to look inside the wrapper (which seems to me to
be the most effective approach for everyone). I believe the extra cost of a
few hundred bytes per day for additional ISA/IEAs is worth the price...
Payers' Perspective
My current position is with Coventry Health Care, a
nationally based Health Insurer. We currently receive our Inbound 837
claims from WebMD. We also receive Authorization requests from WebMD in a
proprietary format. We send to them a number of other transactions,
including 835 remittance information.
This is all accomplished through the use of a T1 line and the FTP Protocol.
No file encryption involved.
For our inbound enrollment data, some of it does come to us utilizing PGP
file encryption, and other data we dial out and retrieve using FTP, ZMODEM,
and even old XMODEM.
Prior to coming to Coventry, I was with one of the nations largest Practice
Management Software companies, now called Misys Health Care. They own one
of the largest Clearing Houses as well. All the providers that utilized
that Clearing House did so through the use of a modem and dial up
connection, utilizing FTP to transfer the files. This was for 837 and 835
transactions, as well as reports.
I believe, as it appears to me, most of you do, that the Internet will be
the transfer method of the future. My concern is that this group may have
missed how things are working today and that the vast majority of Providers,
not Hospitals, are not connected to the Internet through their PM Products.
These Providers, for the most part, do not have the staff in place to
implement anything outside of what their PM Software Company provides.
What we will do is return a response to the submitter, depending on if it is
an unknown trading partner or an unknown provider within data from a known
trading partner. We will reject a transaction from an unknown trading partner.
We will front end deny an unknown provider.
We have many obligations related to paying providers. Working an unknown is
not one of them. And I did not see anything in the rules requiring us to do so.
A provider is not our customer, but potentially a trading partner. We have the
liability of properly reporting income to the IRS and state income boards for
payments to that provider. We will insist that they become known, not
necessarily participating, to us before accepting their claims.
We currently use login information at the ISA level. This is then cross
referenced with the system login/password that transmitted the interchange.
Interchange/ISA information is not forwarded to the applicable application.
Within the transactions we would use our business level IDs for the
submitter. We separate security from identification to the application.
(That makes it harder for someone to hack the system and submit business
information) Also, we support multiple business entities submitting
through a singe login/password. (Lots of reasons, too many to get into in
detail.)
I was one of the first people to state that I expect to eventually
see and want a clean, secure, Internet way for Health Care to conduct
Ebusiness. But that is a long way off.
that does not necessarily mean 'open' as I have seen it described
here.
I would submit that, at least with the company with whom I am familiar, we
never accept unsolicited claims, electronic or paper, from providers with whom
we have no established relationship. The blues are perhaps unique in this,
since providers located outside of the service region do not send claims
directly to that blue, but rather to the entity licensed to perform the same
function in that state or region.
We are not going to change the fact that we are fiscally responsible for
paying claims to people actually licensed as providers and accredited by the
state boards. Nor will we accept their assertion, by receiving a properly
formatted claim, that they are who they say they are without some assurance,
spelled contract, that we acknowledge their right to receive that payment.
Nothing in your CPP will assure any auditor, paid paranoiacs that they are, of
the validity of the relationship or the security thereof. Solve that problem,
for free, then we've got some good groundwork.
I talked to a person from a large health insurance carrier the other day
who's been "lurking" on the list. Though we've gotten into a lot of
technical depth here, he's certainly enjoyed the discussion thus far but as someone from the business side, he had a little problem in
putting together just what we're attempting to do. Once I could give him
the 20-second "elevator" pitch on what it all meant, it resonated with
him and he became a "true" believer in the ID & Routing project.
Basically, I told him, any provider who has his NAIC co-code will be
able to *automatically* find out where his EDI "portal" is - and other
technical information - from his electronic Trading Partner Agreement.
He does millions of claims a month, 80% of them electronic, where 90% of
those are direct from the providers using direct dial-up FTP. He wants
to move to the open Internet, where encryption will be necessary. All
these details of FTP addresses and security will be in the e-TPA. And,
additionally, there's no reason the e-TPA couldn't contain a machine
readable version of what he would have had in a "companion" document:
e.g., testing requirements, EFT details, data clarification for
situational elements, etc. etc. He'll be able to eliminate a lot of
paper and in-person communication, and facilitate direct point-to-point
exchange of standard transactions with providers.
Routing Interchanges
It sounds like the electronics biz (EIDX) has some of the same problems
we have when it comes to identification and routing. Just goes to show
you that solutions coming out of our proposed Healthcare CPP Registry
might be generally applicable across all business domains.
Supply-chain, anyone?
Hypothetically, a payer has relationships with two clearinghouses to
receive claims and submit remits: CHA and CHB. A provider sends an 837-I
through CHB which, in turn submits to CHA to reach the payer. This
process takes place due to the connectivity environment between the
payer and CHB which only allows 837-P to be transmitted. The payer
produces an 835 based on that 837. Could the payer submit the 835 to CHB
or should it follow the same route through which came the 837 (via CHA)?
Your hypothetical scenario assumes the payer has an arrangement whereby
all 835s (remittances) are submitted through CHB. Therefore, I suppose,
the payer should return the 835 through CHB. The route whence the 837-I
arrived is irrelevant, and all knowledge of the original claim's path is
long gone. The 837 ceases to exist by the time it gets to adjudication:
it has decayed into any number of atomic claims; see "Requirements
Gathering - Information Flows," (16 Feb 2002) at
http://www.mail-archive.com/routing@wedi.org/msg00219.html.
As far as the provider is concerned, it doesn't matter what
intermediaries are used to return application responses. In this case,
CHB would likely recognize the ISA receiver ID for the provider (since
the 837-I originally came in through CHB from the provider) and know
where to deliver the 835. Even if CHB didn't recognize the receiver ID
(say, the provider was using CHB as an "open portal" to reach the
payer), the clearinghouse could use the Healthcare CPP Registry to look
up the ISA receiver ID and figure out the EDI address of the provider.
TA1 and 997 acknowledgements would probably be treated similarly (i.e.,
there's no X12 requirement that these traverse the same path as the
interchange they're acknowledging).
Parties
Who's arguing about the ISA receiver ID being any other than that of
the end-point receiver? But as I asked Friday, though, couldn't the
"end-point" be a repricer or TPA (as opposed to a payer)? If, as Ronald
Bowron pointed out, a CH is the "end-point" for re-packaging or
aggregation, then the ISA receiver ID would be that of the CH; is that
at all controversial?
We shouldn't get all "wrapped around an axle" on this "financially
responsible party" business. As I described yesterday, if the payer is
using a clearinghouse as his inbound portal, his own ID (perhaps even a
proprietary CH-assigned ID) will probably appear on the ISA. I don't
know what CHs require on the ISA receiver field for aggregated claims
appearing in a single 837, but it's probably not that of the
"financially responsible party" since there would be many such parties
to whom claims are being made (in the single 837).
Actually there's nothing keeping *both* the provider and the payer from
using proprietary formats or NSF, even under HIPAA. If there's only one
CH between them, as long as the CH converts (or is capable of
converting) the data to and from the standard HIPAA formats for at least
a millisecond, all is okay. I think anything going *between* separate
clearinghouses has to be standard transactions, though.
many of the payers are actually going to
contract with CHs as their "front door" for EDI (whether the CHs are
subsidiaries or otherwise), then that CH's identifier could, in fact, be
the identifier that the payer tells us (via the CPP or other manual
method) to place on the claim (in the ISA). It would be assumed, in that
situation, that the CH is acting on behalf of (is the agent for) the
payer, and therefor represents "the financially responsible party" in
its dealings with the provider.
In that case, the CH would have specific arrangements with the payer (a
TPA), that could, in fact, specify conversion to a proprietary format
(such as NSF) for transfer of the claim to the payer. As long as the
claim is transferred from provider to the CH as an 837, the law is
satisfied (as I read it), because the CH would be operating as the
payer's agent.
This is also true in reverse for the providers. Some billing software
will be used by smaller providers to enter claims data, and will then
transfer that data to a central location in a proprietary format (say, a
"flat print image file"). The central location is the billing software's
"hub" - just another CH in our view, but one with a special relation to
the provider - it is the provider's "billing agent"). Again, the law is
satisfied because the CH is the agent of the provider, and it
communicates to payers via the mandated transaction set. One of the
largest provider software suppliers in the country is planning on doing
just that as their "answer" to making the software HIPAA compliant - and
they are licking their chops at the millions of $$ to be made sending
all those claims on behalf of the provider in that really difficult
electronic format (and for only $.25 per claim - what a deal...).
I'm inclined to believe that addressing the receiver should be
independent of who the sender is. So I'm uncomfortable with your
suggestion to use the ISA SENDER ID and the GS SENDER ID for selecting
between alternate "EDI addresses." I think the other items from the
ISA, GS and ST are acceptable for consideration in looking up EDI
addresses.
"ISA ID(s) would probably be guaranteed to
be unique only within the domain of the same VAN." This is true only in
the case of CH (or payer) assigned proprietary IDs. But this group
definitely will be recommending that all parties be identified by global
identifiers (of their own choosing, e.g., DUNS, NAIC, HIN, etc.) - DUNS
04-643-0013 is unambiguously Children's Hospital in Columbus regardless of which VAN or CH is being used.
Unless an interchange is going through a pass-thru intermediary - a
switch or a VAN - which delivers EDI for many entities, it probably
really doesn't matter what's in the receiver field of the ISA, does it?
If I deliver an interchange to Anthem, directly, doesn't it stand to
reason that the interchange is somehow for none other than Anthem?
Maybe Anthem will use the GS envelope for further routing, but would it
even pay attention to the ISA receiver field?
But if the interchange is passed through an intermediary, such as a VAN
or CH, clearly the immediate destination (the VAN or CH) will not be
identified as the receiver on the ISA. The ISA receiver field probably
should be that of the next entity to open the transaction set: this
might be the payer (for a claim), but could just as well be a Re-pricer
or Third Party Administrator - who I assume are not classified as
"payers." Actually, the "real" payer (the insurance company behind a
self-funded Employer plan) may never see standard transactions for a
plan - is it correct in this case, then, to call the payer a "receiver"?
Blues
Blues are perhaps unusual - if I've interpreted some folks including
Robert Barclay and Bob Poiesz correctly - in that claims are submitted
to the provider's local BC/BS, regardless of the Blue the subscriber is
insured with. The local BC/BS serves as kind of a re-pricer before
forwarding the claim to the "home" Blue. Or something like that. See
http://www.mail-archive.com/routing@wedi.org/msg00501.html.
We've talked about the payer's CPP DeliveryChannel ("EDI Address") being
selected on criteria like the plan ID, payer identifier and transaction
function (e.g., batch vs. real-time, claims vs. eligibility request)
alone. But accommodating the Blues' desire to have claims sent to the
provider's local BC/BS adds a bit of complexity. Note that I said
"desire," not "need," because it seems the BC/BS ITS network could just
as easily perform out-of-area forwarding instead of burdening the poor
provider with the problem. Nevertheless, perhaps the folks designing the
Elements of the CPP (electronic Partner Profile) can think of ways that
selection of a DeliveryChannel can be based on attributes of the
inquirer (in effect, the provider's location).
Take the Blues for instance. HIPAA requires that we all accept claims etc.
from providers. But it does NOT mandate how. If I am in Maine, I can say
to a Utah provider "No, you can not send HIPAA transactions to me". And I
will follow that with "My business associate that handles HIPAA
transactions in your area for me is the UTAH Blue Plan - contact them".
Nothing in HIPAA mandates that I do the HIPAA transactions via the same
route or business associate for all providers/trading partners. Now,
somebody can 'say' that I am refusing to obey the law and conduct HIPAA
transactions with that provider, but that is NOT the reality of the
situation. I am just directing the provider to the proper routing for
cliams from that provider to my plan. And, that means that I can not
support 'open' EDI. That would negate my current right to deligate my
HIPAA responsibilities to business associates as I see fit. To my
knowledge, the only restriction under HIPAA is that my business associate
could not charge that provider more that the cost of a long distance
telephone call.
It has been a couple of years since I was involved with ITS/Blue Card but I will give you what I remember. If my
mind wonders too far someone please correct me. The system is more than a convince to providers. It was also
designed to give one Blue plan the benefit of other plan's rates when their subscribers traveled.
So if I am from California and see a doctor in Wisconsin. I give the doctor my Blue membership card which has an
ITS prefix appended to my subscriber number. This prefix is different from the Plan code. The plan code is numeric
and one is issued per plan. The ITS prefix is a three byte alpha ID. There can be more than one ITS ID per plan (i.e.
HMO, PPO, etc...) For example, the plan code for Blue Shield of California is 542 and the ITS prefixes are XEA
(PPO) and XEE (HMO) and there may be more.
The doctor submits the claim to BC/BS United of Wisconsin with my subscriber ID of XEA123456789. Wisconsin
takes the claim and sees that I am a Blue Shield of CA member, based on the XEA prefix. Wisconsin then
determines the local negotiated payment rate and forwards the claim to Blue Shield of CA. Blue Shield then finishes
processing the claim. Then, here is were I am a little fuzzy, I can't remember if Blue Shield then cuts a check/denial
or sends its decision to Wisconsin where the check/denial is created. Anyway, you get the idea. This is more than a
clearinghouse arrangement. The participating Blue plans are acting as pre-pricers for each other.
The Local Plan, where the provider is located, accepts a transaction and
contacts the Plan where the member is from to determine if the person is
eligible for coverage, whether the coverage includes the service provided,
and what copays or coinsurance should be applied.
Upon receiving this response, the Local Plan processes the claim and
responds to the provider.
The choice for the provider is whether they want to connect to one local
Plan or 50 some odd Plans all around the country.
As for using the Blue Plan identifier, not all Plans want to use that
identifier on the standard transactions. The ones I am familiar with are
using the NAIC code. Furthermore, with HHS slated to issue a Payer ID
regulation, I think you will find it difficult to influence Plans to change
their processes prior to the HHS regulation being issued.
Functional Group
I don't have any strong feelings one way or another. In the health care
supply chain sector, the common practice has been to use the same values at
both the ISA and GS levels.....unless the sender and receiver agreed to use
the GS identifiers to identify, for example, a business unit or operating
unit within a larger enterprise. This is how I implemented the use in
1985-87 at Baxter Healthcare. I believe that this is common practice in
other industries as well, i.e., the same values at both ISA/GS......
For HIPAA, I could certainly envision a payer, for example, specifying a GS
receiver code(s) for one or more adjudication systems and other GS receiver
codes for other types of transactions. This is closer to the original
intent. When this approach is used your EDI translator can then output the
correct file to the correct backend adjudication system.
Unfortunately, the original intent is not documented and all that we're left
with in the standard is the data element name. It's just the old-timer's
like me that remember some of this history!!! Personally, I think it's
unfortunate that the HIPAA guides haven't provided for explicit guidance for
the novices for not only the use of the ISA/GS identifiers, but also the
other standard acknowledgments, such as the TA1 and the 997. As you know,
confusion reigns!!!
I think that what has happened is that many people have not needed to use
the GS for the original purpose. As a result, they have defaulted its
function to being a restatement of the ISA values. That is different than
morphing. Its fine to retain that default content when no other need
exists. But it would be detrimental to assume that you could eliminate the
other (original and primary) use and only leave the default. The fact is
that these are not the sender and receiver ID. They are something
different. I assume that by your "...but..." you are not in favor of
retaining that original functionality (I apologize if I have misread that
point). I believe that eliminating the "Application" capability from the GS
would be a mistake.
The GS segment does not have either a Sender ID or a Receiver ID. What it
has is an Application Sender's Code and an Application Receiver's Code.
These are very different. They are intended to be used for routing and
translation map identification. We are using these elements to determine
both routing and mapping. In some cases, we need this information to
determine which application gets the data.
In fact, I would say that the GS elements can not be standardized.
The 270/271 implementation guide makes some recommendations on how to
distinguish between Batch and Real Time transactions:
If trading partners are going to engage in both real time
and batch eligibility, it is recommended that they identify
the method they are using. One suggested way of identifying
this is by using different identifiers for real time and
batch in GS02 (Application Sender's Code) for the 270
transaction. A second suggested way is to add an extra
letter to the identifier in GS02 (Application Sender's Code)
for the 270 transaction, such as "B" for batch and "R" for
real time. Regardless of the methodology used, this will
avoid the problems associated with batch eligibility
transactions getting into a real time processing environment
and vice versa.
Overloading the GS sender code (using solely for internal routing by the
recipient) is certainly preferable to requiring different sender or
receiver IDs in the ISA, depending on Batch or real-time. But unless we
come up with specific recommendations that apply across the board - for
every provider and payer - stuff like what's in the IG will require a
TPA (or "companion document"). We want to remove the need for TPAs,
right?
Anybody have specific ideas for differentiating batch from real-time?
How about keying in on BHT03 - the Submitter Transaction Identifier?
It's required to be used (in the 270) if the transaction is processed in
Real Time - and since it can only be returned in a real-time 271
response, it seems like a most excellent marker. I do realize that
makes it tougher for the payer to distinguish between batch and
real-time inquiries, in that you have to drill into the bowels of the
transaction set before knowing which queue to insert the request - but
is that any more difficult than relying on the GS?
Testing
In a "test" mode, it would seem easier to pack only "test" transactions
into an interchange anyway... so the T/P indicator should be useful right
where it is. But the CPP record could certainly carry information that
supports other ways of distinguishing test from real data.
In my experience with the ISA I14 is that people generally ignore it
which is not to say it can't work. Most organizations do not have tight
enough controls to trust that they use the ISA I14 correctly.
Re: Testing. The ISA I14 Usage Indicator (e.g., P for Production Data,
T for Test Data) applies to the entire interchange - we can't change the
X12 standards here. I'd say just put the production transactions (and
functional groups) in one production interchange, and the test
transactions in another. This technique requires nothing of the CPP,
since theoretically a test interchange is sent to the same portal using
the same IDs in the ISA as production data.
Unlike the ISA I14 T/P indicator, which is universally understood - if
not universally implemented, some (or most) organizations demand that
test interchanges be sent using a "testing" ISA receiver ID. I think
we can handle this, too. There's nothing to keep us from adding the
capability into the CPP for specifying a Test ID and Qualifier - along
with the production pair. This would be done on a Delivery Channel
("EDI Address") basis, with some means to differentiate the production
and test (and maybe even "real-time") ISA receiver ID and qualifier
pairs. For example, in effect, the CPP would say if you end up using
Delivery Channel X, then production data is sent with the ISA receiver
field saying NAIC co-code 54901, but a test interchange would be sent
with the "mutually defined" ID "54901TEST" - the NAIC with "TEST"
appended. This is an augmentation of what we discussed before, where
the CPP specifies what's stuck in the ISA receiver field depending on
the circumstances; see "Why do we flap our lips so much....," at
http://www.mail-archive.com/routing%40wedi.org/msg00438.html, from 12
April.
It would be nice if everyone had the ability to process transactions
based on the testing indicator as recommended by the X12 User Guides.
And that all the information in the ISA would be used for both
Production and Testing. Then the only data element to change when going
live would be the Test/Production indicator. The problem with this
indicator is it is not transaction specific - therefore it assumes all
transaction within the interchange are valid for production. This is
not always the case - for example, an entity may be in production with
sending eligibility requests, but not claims.
Also, not many institutions have used the T/P indicator properly. Most
organizations didn't setup their test environments to represent their
production environments when it comes to sender and receiver ID's.
Therefore, a sender may have one ID for testing and another for
production - assuming the ID is dictated by the receiver (i.e. via ZZ
codes). It's possible that some may consider building x-ref tables to
address this and the use of standard identifiers like the D&B numbers.
Packaging
I believe we are attempting to create a blueprint here for massively
enabling communication between "EDI veterans" and a [possibly] large # of
EDI neophytes (doctors, labs, DME suppliers, etc.). If the Big Boys are
currently using "creative" implementations of the ISA information, I don't
think that should deter us from recommending that the ISA be used exactly
the way the standard envisioned it. If providers do enable themselves to
create X12 interchanges, I would not be surprised to see lots of ISA/ISE
envelopes containing a single transaction (e.g., a "real time" 270) or an
interchange with 4 or 5 claims in it. Large batches of different
transactions with multiple addressees is probably an artifact caused by the
mere existence of the traditional form of the CH industry. As the CH
industry develops new value-added services to support a model in which
payors and providers collaborate more directly through EDI, then I suspect
interchanges to get smaller and become more homogenous and more numerous.
Portals
The Web Services "paradigm" is not exactly analogous to what we're
grappling with here. But even if it were apt, shouldn't your conclusion
be that the *submitter* (or requestor) do the splitting? - i.e., choose
among the (possibly many) "addresses" to forward his interchange to?
Yes, the payer - through his CPP - is offering "services" to the
provider: saying, in effect, "we do all these types of transactions:
837, 270-271, 835, 834, 276-277, etc." But should the provider have to
make the decisions to implement the split - i.e., decide to send the 270
to the payer's designated "real-time" portal, and 837s to the payer's
"batch" portal? Or should the payer always make it easy on the provider
by saying "Send everything to this one portal," and then separate 270s
from 837s for subsequent processing behind the scenes?
don't believe that it's practical or reliable **today** to assume that the
provider can select or determine how to address and where to send a given
instance of a HIPAA transaction.
I suspect that many payers' architectures have evolved over the years as new
transactions and capabilities were added to their business offerings, and as
a result, there are several portals into/out of the organization depending
on the type of transaction, the timeframe in which that transaction is to be
processed, the destination backend system, and so on. I don't believe it's
reasonable to expect payers to totally re-architect their systems
environment in the short term, solely in response to the HIPAA transactions
requirements.
A similar architecture most likely exists at many providers, especially the
large multi-facility provider organizations, where disparate and disjoint
systems initiate a variety of transactions, and where these transactions
leave the organization through several exit points.
An ideal architecture would/could be one of a single portal that would have
the ability to immediately detect the type of transaction being presented
and the expected timeframe within which that transaction should be processed
and then appropriately address, envelope, route and receive, parse and
process accordingly. But, that's an ideal and not in sync with today's
situation.
I will be surprised if this is a significant problem. That being said, I do
not support your suggestion that this problem be laid at the doorstep of
payers.
I suspect it is true of most payers that they maintain eligibility on a
different platform than claims. In fact, the data is probably on multiple
platforms -- one for enrollment style information, another for benefit plan
related information, yet another for information about deductible and
co-insurance accumulators.
That fact notwithstanding, given how much trouble it is to get one
translator set up I can't see plans setting up a separate entry point for
each transaction.
What may occur is that Payors may prefer that transactions from a
professional provider (e.g. doctors) go in through a different gateway that
transactions from facility providers. This is likely to be true when doing
business with a Blue Cross Blue Shield Plan and the member has non-HMO
coverage. The reason is historical -- the BCBS Plan probably still is set
up with a system for facilities and a system for professionals. However,
even there, if you are doing business with a combined Blue Plan and they
have been combined for some time, they may have unified their enrollment and
eligibility systems.
This may also happen with any carrier (Blue or non-Blue) that outsources
some processing services. This could occur if the carrier outsources
processing of transactions from professional providers. More likely, it
could happen if the carrier outsources processing from specialty providers.
For example, how many carriers interact directly with pharmacists, as
opposed to hiring a PBM to do it? The same is true of behavioral health
providers. Many carriers outsource that interaction to another company.
Remember that self-funded groups are a wild card. In those cases, it may be
the group, not the carrier/TPA that chooses which claims go where. The
members may be carrying an ID card that has a logo from a particular
carrier/TPA, but the provider may be surprised if they try to send a
transaction to that carrier/TPA. That situation is outside the control of
the carrier/TPA.
It is a good point to document. It is a question that providers and
clearinghouses basically need to ask and payers need to try to anticipate
and answer. The responsibility cuts both ways -- it can't be laid just at
the doorstep of payers.
In closing, I offer the following comment as a practical caution. Given the
number of claims I have seen providers mess up -- sending them to the wrong
address, the wrong carrier, empty envelopes, holding them for months before
sending them, etc. and then they go crying to the regulators and legislators
and say that the only reason their accounts receivables stink is because of
big bad carriers -- I can tell you that if someone suggests that providers
don't have to take any responsibility for figuring out where to send things
that person will find carriers very unsympathetic.
Using the transaction set as one component to determine the destination
of an interchange was never defined out of scope. But *requiring*
anything other than what's available in the ISA to determine routing
would place a burden on providers new to the standard transactions - or
their agents (VANs). Altruistically, my concern is motivated solely by
the needs and capabilities of the "little" people (providers).
Generally, anyone producing standard transactions is aware not only of
the ISA sender or receiver fields, but also stuff in the GS and the ST theoretically they could make decisions for routing, selecting the
appropriate node in Kepa's DNS scheme. But it might be asking too much
of their off-the-shelf practice management software to traverse Kepa's
DNS tree (or even to use a CPP type of arrangement). Instead, they (the
providers) should be able to dump all their interchanges into one
conduit and be assured their "stuff" will get there safely, securely and
reliably based solely on receiver ID.
If that conduit were a VAN, wouldn't it be too much to expect the VAN to
burrow within each and every interchange, group and transaction set to
determine routing? It's not impossible, certainly. But, again, why
should the sender (or her agent) have to concern herself with each of
the variables present in the ISA, GS and ST (and possibly more, if you
consider real-time requests which are evident only by looking within the
transaction set) and figure it out on her own where to send the
interchange? Isn't the ISA receiver ID enough? She has already
specified the recipient's NAIC, Plan ID, or whatever, in the ISA. Once
it gets to the payer, I think it should be incumbent on him to figure
out how to internally route the interchange (or functional groups
within).
I know I sound like a broken record, but I doubt very much that many
providers will be dumping transactions into any VAN. The norm will be to
dump the transactions into a clearinghouse. Providers will probably have
direct connects to a few payers with whom they do a large amount of
business, but the rest will be via a clearinghouse. In many cases, that
pre-packaged practice management system will send only to one place, the
vedor/vendor's-selected clearinghouse. The software will force a
submission route that guarantees a revenue stream for the vendor (not that
I like it - it is reality - I have been in touch with at least 1 MAJOR
vendor with that plan).
I believe that there are two probable solutions for the batch/realtime
issue. The majority of the solutions will either use separate channels for
the batch and realtime (different mailboxes), or different values in GS02
as suggested in the 270/271 guide. I believe that you are correct that the
health plan should make sure that they handle the priorities, but I think
the solutions will fall into these 2 main categories.
I haven't looked at the ISB to determine its viability as a technical
solution. The fact that it is not part of the HIPAA guides is not an
impediment, in my opinion. The 997 and TA1 are in the guides, but
specifically not required as part of HIPAA. The unsolicited 277 is not a
HIPAA transaction but at least some are planning to implement it as a claim
pre-adjudication edit report. If willing trading partners wanted to
implement the ISB as a batch/realtime solution, that is outside of the
current scope of HIPAA and not a problem. The only issue would be that a
health plan would not be able to require the ISB in order to accept an
otherwise compliant interchange.
The ISA06 and ISA08 sender and receiver "addresses" should be unique and
not overloaded with extra duty. That's the only way they can be
interpreted unambiguously by all intermediaries. In addition, all the
information needed for correct processing should be contained within the
interchange itself - between the ISA and the IEA - as a self-contained
package because it's too much to expect PM systems to support alternate
"channels" for conveying information to the payer. And besides, the
provider can be anticipated to only have a single "conduit" to the
outside world - his VAN - the simplest model for supporting
inter-company exchange.
Clearinghouse Aggregation
It's important to remember that for any one X12 interchange, there's
only *one* sender (or submitter) and *one* receiver - regardless of the
number of payers or providers whose "stuff" is embedded in a single 837.
To get some boundary on definitions, is it safe to say that the sender
is definitely the guy who creates the ISA? What can we say about the
receiver?
I would submit that our job is only concerned with the identification of
the trading partners (who may be clearinghouses, billing services,
repricers, etc. - not just providers or payers) at the ISA level, and
the issues of routing - what's needed to be known in order get the
interchange from here to there.
What any intermediary - such as a clearinghouse - does with the enclosed
transactions (and functional groups) is simply none of our business project scope-wise. Such a simplifying assumption should assist us in
maintaining focus.
If you're referring to the
"problem" of end-points being only payers or providers (or TPAs), I've
already given out my opinion that I don't think that is much of a
problem. Addressing Clearinghouses can easily be accommodated in our
recommendations.
I'd go a step further, and say that supporting aggregation can be made a
first-class feature of our CPP EDI Address function. Take an example: a
sophisticated provider, like Dave Minch, wants to send standard claim
transactions to 20 payers. He looks these payers up in the Healthcare
CPP Registry, and finds that 10 of the payers are supported by the same
clearinghouse, and that claims for any of the 10 are to be directed to
the same "portal" resident at the clearinghouse.
Normally, Dave could choose to build 10 interchanges, one for each of
the payers, shunting them off to the designated CH portal seriatim. The
CPP for an individual payer might even specify an alternate EDI ID to be
used in the ISA receiver field - i.e., the proprietary CH-assigned payer
ID.
Now imagine this: the CPP for the Clearinghouse (which has been
referred to by the payers' CPPs) says somehow in the Delivery Channel
for claims that claims can be "aggregated," with a special Receiver ID
to be used. This could be of benefit to both Dave and the
Clearinghouse: Dave now can "aggregate," or combine, the claims for all
10 payers (as described previously by Bob Poiesz) into one standard 837.
Maybe there's some obscure advantage to Dave in doing this - as if he'd
run out of incremented transaction set control numbers otherwise; I
don't know - but it's Dave's option to do this as no one is forcing the
provider to perform aggregation.
The CH receives Dave's aggregated 837, and assuming it's
HIPAA-compliant, can then proceed to split and merge, combining other
providers' claims (for the same payer) into consolidated 837s for each
of the payers. Apparently, some payers find this to be a big advantage
in having multiple providers' claims all munged together in the same
837. In any event, there's nothing that keeps our recommendations from
elegantly supporting such "requirements."
But if a provider wants to send a batch of claims to different payers
all bundled up in one 837, for subsequent re-sorting and distribution by
his own clearinghouse, then by all means he should have that choice.
The 837 HIPAA IG doesn't disallow this (it's silent on the issue) therefore his 837 is still considered "HIPAA compliant."
More likely than not, our recommendations have *absolutely* no effect on
this practice: the provider has determined that he would rather deal
with a Clearinghouse and make a single 837, and has arranged with that
Clearinghouse to do the "un-bundling" and aggregation. The provider
will probably not be using our recommendations because he has no need to
address, and route to, individual payers - he has devolved the
responsibility on the CH for finding and routing transactions to the
payers.
I see no reason to act as if this practice is offensive. It isn't. But
it's also one that really doesn't have to be documented in our
recommendations, for the simple reason if you always package up 837s for
your own Clearinghouse, you hardly have to go about "discovering" its
EDI address.
It's important to remember that our recommendations are to effect the
efficient, safe and secure routing of standard transactions between
business partners - to describe a method for providers to discover where
the heck they should send the stuff once they've gone to the trouble of
building standard transactions. A provider who prefers to always use a
CH has no need for our recommendations.
Switch Intermediaries
If we do address the auditing issue, am I safe in saying that our
concern should be limited to making recommendations for keeping track of
an (intact) interchange as it hops through intermediaries on the way to
the receiver?
If so, usage of the TA1 (Interchange Acknowledgment), transaction set
997 (Functional Acknowledgment) and transaction set 242 (Data Status
Tracking) are all within our purview. The 997 and TA1 are covered in
the HIPAA IGs; the X12 242 transaction is used between intermediaries
(e.g. VANs) to say what the disposition was of interchanges as they
passed through interconnections.
Once an interchange has been opened, tracking and auditing probably
relies on application segments (perhaps the 837 Loop ID-1000), and thus
is out of scope for this project.
Open-EDI
Payers will have to be prepared for taking in anything coming along from
providers - if they would have taken paper before, they can't put
roadblocks up discriminating against the equivalent Federally mandated
HIPAA standard transactions! Not only will they have to make available
an open portal for receiving electronic claims and eligibility inquiries
(advertised in our Healthcare CPP Registry), but they will have to make
sure their translators can accommodate ISA senders they've never seen
before.
1. It is potentially possible for a payer to receive an electronic claim
from a non-participating provider
2. The payer cannot refuse to receive the claim
3. The payer is not obligated to process/adjudicate the claim
4. The payer, in my opinion, should anticipate the potential for receiving
electronic claims from unknown providers and have a procedure for dealing
with them
5. This process would be no different than what happens today if a payer
receives a paper claim from a non-par provider....what do you do with it?
The real radical notion is this Open-EDI I'm talking about - though it
seems few payers are thinking along these lines. Remember: "A health
plan may not refuse to process a transaction simply because it is a
standard transaction." I can't but think if a payer would have taken a
paper claim (from a par *or* non-par provider), they absolutely must
take the HIPAA standard transaction, the absence of a trading partner
agreement or "certification" notwithstanding.
We do hope that no mis-routing of claims will happen - that's where the
Healthcare CPP Registry will help: if you have the plan's identifier,
you'll get the correct CPP, which points to the plan's open portal.
I agree, up to a point. But I still say that a form of pre-qualification
must exist, at the trading partner level. The last thing I want to do,
as a payer, is disclose eligibility data about one of my customers to
someone not eligible to receive said data, also a clear violation of the
only part of HIPAA with judicial recourse. And that puts us back to a
trusted relationship with whomever is requesting the information.
In the electronic analog of this story, the payer will have to accept
standard 837s from the "unknown" OSU. The payer took OSU's paper
claim; the law is clear that it will also have to take a file formatted
according to the HIPAA IG. Which leads to the need for the Healthcare
CPP registry: (1) OSU would have to have some (easy) means of finding
Anthem's (free) electronic portal for submitting standard transactions,
and (2) Anthem would need some way to find OSU's portal for returning
responses (technical acknowledgements, like the TA1 and 997, and
application acks like the 835 EOB).
I'm NOT saying, under HIPAA, that ANY payer has the option of not accepting
a valid 837 based on the provider's non-participation status with said
payer.
We did have a policy like that some years ago. I believe some other
payers may still.
It was better for the bottom line to take in as many receipts as we could
via EDI, so we dropped that restriction.
We have NO intention of restricting submission of claims to participating
providers.
Our TPA's will not include any restrictive clauses not allowed in §162.915.
We are writing our processes to the IG's trying to allow for as much
flexibility on the submitters part as possible by including a lot of new
business intelligence logic. We will only be including requirements that,
if not met, will cause the transaction to be unprocessable by us. While
these requirements (primarily codes) are specific to the HIPAA IG's, they
correlate directly to elements contained in a paper submission. Bad data is
bad data.
If a covered entity wishes to conduct a standard transaction with us, we
will accommodate their request, set them up and take their data or, if the
transaction is an outbound transaction like the 835, we will start routing
the data to the portal identified during the set-up. Their claims
generation and accounts receivables may not be on the same platform or use
the same transmission medium. We are not, in any way discriminating against
submitters who want to conduct standard transactions. We have no intention
of violating any clauses under §162.925. The closest thing we have here the
necessary *adversity* of bullet "(2)": (Allowing us to set-up the submitter
in our system in order to reliably conduct the transaction(s)). There has
to be some reasonable thought applied to all of this. Certain things are
just understood under HIPAA. Certain questions are never asked. Like...
If we wished to do away with paper Explanations Of Benefits in favor of
HIPAA-standard 835's, must all providers we process a claim for be able to
receive an 835?
I don't want to see this whole thing revert back to business as it has been
done in the past and welcome the automation possibilities available to all
of us under HIPAA. We should have been able to do all of this long ago
without federal mandates, but we didn't. If we assume, now, that it's just
a matter of opening all the spigots, I'm afraid we'll all drown.
Q. Would you ever be sending claims to insurance companies you normally
never dealt with?
A: Most of our business is done under some sort of contract - where we
have agreed upon certain rate schedules and service lines in advance
with the health plan. We do also operate a regional trauma unit through
which we get patients from all over the US and abroad, and we do a lot
of billing to payers with whom we have no pre-existing relationship.
Q. Would you be doing this on behalf of the patient? - if so, would
payment usually go to the patient (on the assumption he paid you up
front)?
A: Technically, all billing done by us is on behalf of the patient.
Financial responsibility is the Guarantor's in ALL cases - even with
programs such as Medicare, Medicaid, and Champus. This is because the
Guarantor can always authorize procedures and other expenditures which
go beyond the care covered by any particular plan. We direct bill payers
as a service to the patient (and, of course, because the patient could
never figure out how to navigate the reimbursement waters by
themselves). It also assures us that we will get the bulk of our payment
in a somewhat timely manner.
If the patient or guarantor cannot provide us with a verifiable plan
prior to delivery of service, then we will bill the patient/guarantor
for charges. If they pay, then we are generally done with that account we would not bill after-the-fact on behalf of the patient. What does
happen is that the patient will pay some of the bill (or pay deductibles
which we later find have already been satisfied), and then present us
with a verifiable plan, where upon we will bill that plan (payable to
us) and refund any over-payment back to the patient.
History
It's good that Scott has identified this. Many of us EDI people should have
recalled the Open-edi Reference Model and SITG since many of us, myself
included, helped to develop these documents and actively participated in
SITG (Strategic Implementation Task Group) of X12.
UN/CEFACT/TMWG (and its predecessor AC.1) produced a document (N010) the
Next Generation EDI Reference Model, which included the concept of
discovering the capabilities of trading partner using electronic means. The
development of this document started in the 1995-1996 timeframe, evolving
from IDEF modeling techniques to UML. This effort determined that Open-edi
scenarios could be modeled as use case scenarios. The N010 document was the
stepping stone to N090 or UMM as we know it.
X12 also has the Trading Partner Profile (X12 838), first introduced at
version release 3020 in the early 90's as well. It has several segments
that provided information about transaction capabilities (TXN) and
information about business applications (ENE) at a company. It was intended
to configure new trading partners but few people really knew how to do this,
or wanted to, because by that time AI techniques had a bad rap.
Auto-configuration was never completely possible, since all the
implementation guideline were different.
X12's SITG also participated with TMWG to work on both N010 and N090. IBM
was invited by SITG to speak at X12 to discuss their efforts on Long Running
Transactions, and speaker was our friend Marty Sachs. We thought this was
an information sharing event at the time. Most know that Marty's R&D
ultimately evolved into tpaML.
Open Portals
Today, an open door can not work. There ARE security issues and
connectivity issues and identification issues and contract issues and
validation issues and - well, you get the point. We can not ignore those
or just make them go away.
But, there must also be a vision for the future. I have had that vision
for years, and shared it here. But, that IS very much a future vision
today. We should be able to use the internet for open healthcare EDI. But
that requires security and non-repudiation solutions and databases that
provide identification and routing and validation and connectivity
information. We do not have those today. This is not a simple situation.
The problem that I see with the current discussion is that we are not
actively recognizing that we have a today and a future. The talk often
sounds like one side saying "The future is here, accept it" and the other
side saying "I am not ready for it".
As I recall from the beginning, the focus was on trying to establish a
direction for the future vision and to facilitate the move to that future,
not to impose the future. And, this group's focus is on only part of the
total problem.
You make it sound as if payers will be obligated to open their gateways,
carte blanch, to any who wish to direct a file our way. While there may, in
the past, for some payers, have been requirements that a provider must be
"participating" in order to submit their claims electronically or otherwise
capitalize on their EDI investment(s), that in no way means that we have to
take in a file from entities we haven't entered into a Trading Partner
Agreement with and set up in our system(s)(participating or not).
If a provider were to unilaterally determine how to route data to us and get
it wrong, it would increase the chance that we might be receiving another
carriers information in error. There is also the issue of our not being
able to process their information or inquiry as certain basic identifiers
(part of the TPA) were not used or used correctly. I know it flies in the
face of admin simp., but, until all the identifiers are finalized, we will
have TPA's that look a lot like what we have today.
And by no means did I have say that a payer has to adjudiciate every claim
received. Only that there is the potential to receive a claim from an
unknown (to you) provider and that you cannot reject it out of hand. You at
least have to take it in through your electronic mailroom and then decide
what to do with it the same as you would have to do with a paper claim that
hit your paper mailroom. This is where the TA1 segment could be used since
of course, your EDI system won't recognize the ISA sender (or perhaps it
could, if the sender was a clearinghouse with which you already do business
and the provider isn't known until you peel back the transaction.) In that
case, what do you plan to do?
We do anticipate receiving data from both par and non-par
providers and processing/adjudicating those claims. If we receive claims
from providers we can't identify or discern from what was received, they are
not/will not be adjudicated whether they are received on paper or via EDI.
Additionally, we reserve the right to not load data into our system that is
coming from a submitter (which may be a provider) we don't know.
I guess you could say my e-mail server is an "open portal." You never
know what's going to come across; see below. Now even without examining
the headers (which probably aren't forged, otherwise the spaminator
would've discarded the message), I can tell I needn't bother with this
e-mail. But it did require me to read at least one paragraph of the
missive.
This is analogous to a payer simply reading the (purported) EDI file
coming in on the open portal: if it doesn't have the correct HTTP or
MIME headers, for example, somebody's completely wasting your time, and
it can be discarded or rejected with an HTTP response code or bounce
e-mail. Same thing if you can't decrypt the S/MIME with your private
key or make out an ISA in the body or an attachment. Once you do get
the start of an interchange, if the remainder doesn't conform to X12
syntax, a negative TA1 or 997 can be returned. If it looks like good
EDI, but doesn't comply with the HIPAA IG, an 824 can be returned.
Of course, maybe I have the order things are done all wrong here, and
it's certainly more complicated than this depending on the protocol and
packaging, but you get the drift. Keep in mind that IETF EDIINT AS1 and
AS2 implemented by many commercial software packages takes care of a lot
of these details in a well-defined sequence.
But suffice it to say, for those payers worried about viruses and fraud,
it's clear a scofflaw isn't going to get too far if he can't fake a good
transaction with the proper transport and packaging. And if he can fake
a seemingly valid 837 using the proper segments, situational elements,
codes, dates and IDs, hire him, 'cause a lot of smart folks are hung up
over these very issues all over the country.
Assume a correctly formatted 837 got past this gauntlet, and it's from
an "unknown" provider. For those payers still suspicious of the EDI and
any "cooties" contained within, I suppose there's always the option of
taking the 837 and printing it out on a HCFA 1500 or UB92 claim form,
pretending as if it came in the mail or on the fax! At that point, the
payer is home free: there's now no danger of "disadvantaging" standard
transactions vis-à-vis paper! Somebody could even make a cottage
industry doing exactly this: taking in standard transactions and
dropping them to paper.
Actually, come to think of it, clearinghouses do this all the time! So
a payer, in this case, would have his "open portal" maintained at the
clearinghouse - a free conduit unburdened by logons, passwords, fees
and subscriptions. The payer's CPP Electronic Partner Profile Delivery
Channel ("EDI Address") would simply point to the clearinghouse.
Standard transactions coming from "known" partners would be passed
through to the payer as EDI, and "unknown" providers would have their
stuff dumped to paper. If somehow that makes the payer happy (though
Lord knows why), that's perfectly compliant with the law which says
nothing about "disadvantaging" unknown or non-par providers vis-à-vis
participating providers.
I think we've beaten this dead horse long enough. Payers must maintain
open portals for accepting standard transactions. The HIPAA TCS Rule
requires payers to take in standard transactions on a non-discriminatory
basis: no "vetting," no "certification," no "enrollment," no nothing,
period.
Clearinghouses could have taken care of trust issues between payers and
"unknown" or non-par providers long ago, but payers would not hear of
it. Kepa Zubeldia and Marcallee Jackson have written about an EDI
"Power of Attorney" concept which never gained any traction. This PoA
would allow CHs to automatically sign up providers (customers of the CH)
with payers, saving the provider the heartbreak of onerous and manual
EDI enrollment. See Kepa's sad story at Synaptek (a clearinghouse), in
Re: Trading Partner Agreements, from 05 Mar 2002, at
http://www.mail-archive.com/routing@wedi.org/msg00296.html.
Open portals are not a matter of blind trust. A payer merely has to
accept a file purported to be a standard transaction from any source
(which could be a BA or CH acting on behalf of a provider); he would
still presumably go through the same processes he would with a paper
claim. If the file is not a correctly formatted standard transaction, a
TA1 or 997 will suffice to express the payer's displeasure. These are
text files - no one is asking the payer to "execute" viruses or
executables within the transactions. The payer simply has to read the
data, and discard it if it doesn't even begin to look like EDI (no ISA,
for example). It would be very bad system design to load the file into
memory and begin executing the byte codes: that's about the only way I
imagine a payer could get bitten with viruses!
Key exchange is not necessary before a signed and encrypted file is
read. The file is encrypted with the payer's *public* key, which he has
freely made available to partners via the CPP Electronic Trading Partner
Profile. The payer uses his own private key to decrypt the file. He
can authenticate the source of the file by checking the signature
against the public key supplied in an X.509 certificate pointed to by
the purported provider's CPP. There is no "exchange" of keys: payers
are expected to use and support standard ITU X.509 certificates. It is
unreasonable to expect providers to use PGP whose PKI necessarily
depends on out-of-band exchange of certificates for applying trusted
signatures; PGP will be unsuitable for all but the most insular trading
communities.
Rigorous testing, and perhaps even certification, is highly recommended
for providers. But when push comes to shove, the spirit of the law
mandates the payer must take purported standard transactions - no ifs,
ands or buts. If they're not compliant standard transactions for some
reason, the payer is perfectly within his rights to return a TA1, 997,
824 or an e-mail, depending on the circumstances, clearly indicating
where the first problem was found.
Your company doesn't require me to become "certified" for e-mail before
I send my first e-mail to you, does it? No, of course not: if I don't
follow MIME or S/MIME conventions, you simply reject the e-mail - even
though it eats up some of your precious processor cycles. The same
logic attends standard HIPAA transactions: if the provider has made
even one mistake, tell him so and then forget about it. Nobody's asking
payers to agonize over provider's syntax and semantic errors in the
standard transactions.
The HIPAA TCS Rule requires payers to take in standard transactions on a
non-discriminatory basis: no "vetting", no "certification," no
"enrollment," no nothing, period. As Rachel has reminded us, no payer
has to adjudicate every claim received - he only has to receive it and
cannot reject it out of hand simply because it is a standard
transaction.
But when H-day arrives, an 800 number is no substitute under HIPAA for
processing of eligibility inquiries: all payers must support the 270/271
Health Care Eligibility Benefit Inquiry and Response standard
transaction sets. If a payer's support of the 270/271 sucks compared to
its 800 number or DDE capabilities, that supposedly is a HIPAA
violation (because it would discourage a provider from using the
standard 270).
Listen folks: I didn't make the law. But at least here in the ID &
Routing group, we can try to put together a framework whereby payers can
easily support the 271 standard transactions when submitted a 270 by any
provider. This is as clear-cut a case as I've ever seen of payers
having to take in standard transactions on a non-discriminatory basis:
no "vetting", no "certification," no "enrollment," no nothing, period just like the 800 number.
Overall, I believe we have the same conceptual picture of what the HIPAA
world should look like.
But, till we truly have a standard, as envisioned, with all the appropriate
identifiers locked-down, we won't be able to play effectively in that
sandbox.
As a payer, I can say, we are committed to building the best transaction
processing capabilities we can.
However... Whether we receive an unknown provider identifier on paper or
via EDI, the result is the same. We can't process the bad info and need to
get a response back to the provider telling them so. How we get the
response back is really the only variable here. Of course we could attempt
to determine who the provider is with the available information (which we
do) and cut a check to his neighbor (which we do sometimes with both paper
and EDI receipts), but it's a lot more work for all involved.
Of course we'll have the same problems with Employer, Payer and Patient
identifiers as well. Just at different levels and points along the way.
Clearinghouses and VANs
The open-portal concept certainly does not exclude VANs from
participating. Sure, VANs have setup considerations for their *own*
customers - as do Healthcare clearinghouses. But how often does one
sign up for a VAN or Clearinghouse? - probably not too often: you only
need the services of one of them (assuming yours can interconnect with
other intermediaries and switches). There's nothing in our model to
keep a provider from sending all of its standard transactions through
its own VAN (or CH), who in turn uses the Healthcare CPP Registry to
figure out how to send interchanges to "unknown" payers' open-portals.
Likewise, a Healthcare entity may very well host its "open-portal" at a
VAN (or CH), and its CPP's EDI Address would simply reflect the address
of the intermediary.
Ed showed an example of a VAN actually "drilling" into the
interchange to discover the functional group to determine whether the
interchange would be delivered via "fast-batch" - this is directly
analogous to an intermediary drilling into the interchange to discover
that an eligibility inquiry was being sent (functional group "HS") and
could accordingly use a different EDI address for real-time connect.
I'm guessing at the scenario, but this all seems perfectly natural:
hundreds of little providers send their claims to a CH in whatever form
they can (e.g., paper or proprietary electronic). The CH combines
claims from all providers destined for Highmark (or its affiliates) and
builds one nice 837 for you. When you receive the 837 from the CH, you
politely respond with a 997 to that CH, using the CH's ID in the
receiver field. Nice and symmetric. So, who has a problem with this?
I didn't ask what the CH's ID looked like, but if it isn't already a
globally unique ID like the DUNS, I'm hoping that we can get it there.
The closest thing we have to that today is the clearinghouse network.
Clearinghouses can take care of these trust issues. The problem is that
there is an notion out there that HIPAA is a way to eliminate the need for
clearinghouses. When we talk of open portals, that is what tends to be the
thought. The reality is that a provider in Wisconsin can get a claim to a
payer in New York by utilizing a clearinghouse network (I like to think in
the majority of cases). There are definitely issues associated with that,
such as a lack of total connectivity among clearinghouses. But I think the
alternative is a Healthcare Network of Trust, such as the ATM network in
banking. I do not know if that is realistic. And the alternative of blind
trust is one that I am not willing to accept.
I agree with others on this listserv who have said that VANs and
Clearinghouses will/could use the same or functionally equivalent "Special
Software", which I interpret to be addressing software that uses CPP
addressing methodologies for subsequent distribution on the Internet or
Intranet. This "Special Software" functionality would be standard and
could be developed by individual trading partners, HIS and PMS vendors and
any VAN or Clearinghouse. The business decision concerning whether a
trading partner uses a VAN or Clearinghouse, or "Special Software" will in
large part be made on price, availability, and ease-of-use (and additional
considerations, especially other VAN or Clearinghouse value added services
). However if trading partners, including large and small providers, are
otherwise HIPAA compliant, they will use the solution that best meets their
needs, and many (probably most) will make the decision largely on cost.
Accordingly, to the extent that health plans and/or the HIS and PMS vendors
develop easy-to-use "Special Software" and integrate it into their systems
for less than what a VAN or Clearinghouse would charge, I suspect many
trading partners would use it -- especially if the VANs or Clearinghouses
don't provide other value added services.
see no need to explicitly focus our recommendations on direct
point-to-point to the exclusion of clearinghouses. The discussions to
date have talked about Delivery Channels within the CPP which are
somewhat capable of supporting clearinghouses.
Actually, intermediaries - like VANs and CHs - will be able to use our
recommendations just fine. I can imagine a provider contracting with a
CH intermediary for all communications. Thus, the CH will benefit by
being able to discover where the provider's partners (payers, TPAs,
etc.) are automatically - and they certainly won't all be customers of
the CH itself. The provider in this case has delegated the task of
looking up and discovering CPPs to the CH - which itself is a valuable
service (that the CH can tout).
But having said that, providers themselves who have contracted with
clearinghouses have no direct need for our recommendations. The
recommendations will be of most value for providers and payers (and CHs,
TPAs, billers and repricers) who wish to connect to each other directly.
A clearinghouse can receive 10 837s from 10 providers. Each
provider can be sending claims to 10 different payers in their 837. When
the clearinghouse resorts and organizes the claims they produce 10 837s
for each of the 10 payers that contain claims from each of the 10
providers. Each 837 from the CH to a payer contains claims from multiple
original senders. Each 837 from a provider contains claims for multiple
ultimate receivers.
For what it's worth, the design and requirements of our EDI interface use
point-to-point sender and receiver ID's in the ISA. That is, if receiving
a transaction from a clearinghouse, that clearinghouse's ID must be the
shown as the sender. I expect that we are not the only payer to work this
way.
Nobody likes sharing their customer list,
although clearinghouses, in order to get provider customers need to at
least share their payer connectivity list.
Internet
I wouldn't at all be surprised to learn that the actual situation of how CMS
really handles communications is much different than its public policy
statements ... and along the lines you outline below.
Unfortunately, I don't see anything in the HIPAA final or proposed regs that
requires the use of the Internet or any other transport method....only that
if the Internet is used, encryption is required.
So....I guest that the bottom line is that CMS can choose to go a different
direction and not use the Internet, even though it has an Internet policy
that would seem to allow it???
While the presentation I made includes a bullet as stated to emphasize the
point made during the presentation, the dialog went on to explain the
difference between the open internet, use of the internet as a private
network when the appropriate security is used, and how confusing this all is
to the lay person. The dialog continued to say that Medicare does allow their
contractors to offer the use of the internet protocols (not 'open internet')
but there are some steps (e.g. 128-bit encryption) to follow before
transactions containing PHI can be sent over the internet. These steps assure
the secured transmission while using internet protocols, and are specified by
CMS for Medicare.
The point is that telecommunication exchange of HIPAA transactions is not
specified by the regulation and industry interpretation of 'over the
internet' is inconsistent.
We would all benefit from some consistency here, even if only to understand
the terms, our options of 'over the internet', when to secure, how to tell,
and perhaps specific design issues/solutions. I applaud the efforts regarding
telecommunications - past and in progress. I think this could be a 'sleeper'
issue when considering the full suite of HIPAA transactions and
workload/workflow transitioning from today's telecommunication networks that
are based on direct connections between payer-provider to browser-based
connections.
Sited from: (Dated July 24, 2001)
http://www.hcfa.gov/security/fq011399.htm
Can provider and intermediaries/carriers begin using the Internet for
sending and receiving Medicare claims and remittance advices?
No. Although the policy does away with the restriction on use of the
Internet it does not give organizations the authority to begin utilizing
this media without obtaining full coordination and approval from all
parties in the process, including HCFA. Implementation issues remain to
be resolved, and allowances must be made for software and/or hardware
upgrades or changes.
I would agree that the need to be able to specify a variety of transport
methods and protocols goes beyond just what CMS requires....but it's
incorrect to presume that CMS prohibits the use of the Internet. See my
other post with CMS' current Internet policies
Encryption is required if you are going over an open network, meaning the
Internet. This was reaffirmed by Bill Braithwaite in Chicago last week, who
is now in private practice but was there when the final security rules were
written even if they haven't been published yet. But if the network is
itself secure, such as dial-in, leased line, VPN, then encryption is not
required.
Trust and Authentication
Though I don't see the AMA providing any VAN services, I do definitely
see the value of the AMA-Verisign relationship. The AMA already knows
all of their members, and those members' initial contact points. By
merely giving the membership list to Verisign, the latter is guaranteed
a good list of presumably vouched-for physicians. This information can
be used by Verisign in a high-quality targeted "recruitment" of
physicians for digital ID services. Since the AMA information is
derived in an "out-of-band" context, in-person presentation of
credentials (which adds to the horrific cost of digital certificates)
might be avoided.
One of the uses of these digital IDs might be in EDI: If a payer
receives a transaction from a provider, who has digitally signed his
payload with one of these Verisign signed (on the AMA's behalf)
certificates, it can be reasonably assured that it came from the real
doctor (as opposed to an impersonator). How one determines whether a
particular AMA certificate correlates with a transaction identified by
National Provider ID or proprietary payer-assigned ID is another
matter - the devil's in the details!
We mustn't lose sight of the role security (and PKI) plays in all of the
recommendations we come up with. Even if Kepa's DNS "directory" works
flawlessly and effortlessly for locating EDI Trading Partner information
given an identifier, it's all for naught if any 13-year old in his
bedroom can impersonate a provider (or a payer). The last thing we
would want to see is Harry Hacker pretending to be Highmark by
commandeering Kepa's DNS node 54771.NAIC.HIPAA.NET: every provider
relying on the DNS "directory" wanting to send claims to Highmark could
have them intercepted by the hacker if a PKI is not in place!
The ebXML initiative has looked at quite a few of the security aspects
of maintaining a reliable Registry and Repository (for containing CPPs the ebXML version of an Electronic Trading Partner Agreement). See
https://www.oasis-open.org/committees/regrep/. Frankly, I think Kepa's
DNS "directory" scheme is considerably less bloated than ebXML's effort,
and can be implemented today within the HIPAA community. Having said
that, maybe it's still worthwhile to look at the ebXML RegRep to see if
there's something we can use or learn from.
Digital signatures require digital IDs or certificates which have
themselves been signed by a trusted third party - a "Certificate
Authority," or CA. Ronald Bowron pointed us last Friday to an example
of such a CA, Verisign, who was collaborating with the AMA to certify
providers' digital certificates. Presumably, the AMA is the expert in
identifying doctors, so this certificate authorization model makes sense
on the surface.
The Thawte notary model that Ronald asked about has the same weaknesses
that any certification service has which is based on in-person
presentation of credentials: those credentials are easily
counterfeited. For example, the Thawte notaries rely on in-person
presentation of a driver's license. I guess it kind of gives you some
low-level assurance that an e-mail persona is possibly someone named on
the driver's license - and that may be good enough in most cases. You
have to ascertain the level of risk you're willing to bear relying on
certificates backed by state-issued drivers licenses.
The Verisign EDI Digital certificates go a little further, in that
Verisign vets the submitted information, such as company name, against
Dun & Bradstreet reports and kind of makes sure the applicant really is
with the organization he purports to be with. This service costs nearly
$1000. Is that good enough for a payer to rely on for validating the
identity of a provider submitting claims? Maybe yes, when combined with
procedures where checks are mailed only to the address on file for
participating providers, or to the subscriber for out-of-network claims.
In any event, the methodology - however imperfect - already exists for
"verifying the identity of a CE as part of the TPA process." Our
proposed system might be able to rely on CA-issued certificates which
contain the entity identifiers being authenticated; I think it is out of
scope for our group to worry about how those entities are authenticated
(by the CA) in the first place.
CA-issued certificates should be sufficient for automating the TPA
process. The process for obtaining a certificate is not entirely
onerous on an entity, especially considering it only has to have *one*
digital certificate for trading with *all* potential partners - unlike
the horrible burden placed on it if separate paper TPAs have to be
negotiated with each and every individual trading partner.
For some useful background on Heathcare PKIs, please see stuff about the
AFEHCT/WEDi Healthcare Internet Security Interoperability Pilot at
http://www.afehct.org/security.asp, and PKI in Healthcare at
http://www.healthkey.org/library.htm.
One key issue mentioned in the note is sender authentication. The
concept implied in the note is that the payer and provider set everything up
in advance and establish a means of identifying themselves. That is, they
exchange bilateral keys, usually only a log-in and password, possibly
accompanied by a particular payer's script. Another means is to use the
services of a middle party such as a clearinghouse or switch that establishes
identities. But entity authentication in the future can be accomplished with
more modern means that do not require the overhead of prior bilateral setup
or switches.
All payers - not just Blues - are concerned that they can be assured
they're dealing only with the "Real McCoy." Identification, based on
X.509 certificates, buttresses our entire model.
If I'm not mistaken, Denial of Service (DoS) attacks are often targeted
at the protocol layer: an attacker only needs the IP address of the
"mark" - logon IDs and passwords aren't necessary to commence a DoS
attack. I guess a payer might therefore want to keep his portal's IP
address or URL a "secret," but how long can you hide this kind of stuff
from a hacker? There are technical solutions to thwarting DoS attacks,
but they are out of scope for our project. It's incumbent upon the
payer's network administration staff to solve this problem using
existing methods and technologies. The solution is not to place
barriers in front of providers, forcing them to go through onerous EDI
enrollment processes just so they can submit a HIPAA standard
transaction.
When designing the automated Healthcare Registry for electronic partner
profiles, we can address fraud only insofar as we can guarantee identity
through the use of X.509 technology and CA-signed digital certificates.
We can only assure folks that only the entity which "owns" a particular
ID (e.g., a NAIC company code, Tax ID or National Provider ID) can
create the CPP (electronic partner profile) which purportedly belongs to
it. I addressed this issue in Re: Updated CPP Spreadsheet and Model
Diagram, at http://www.mail-archive.com/routing@wedi.org/msg00575.html.
Re: Fraud and Trust. We can't address fraud, except insofar as we can
guarantee (through X.509 technology and CA-signed digital certificates)
that only the entity which owns a particular ID (e.g., a NAIC co-code)
can create the CPP which purportedly belongs to it. Once you are sure
that you have a CPP really belonging to Saint Therese Hospital in
Waukegan, our job is done. If Saint Therese Hospital's lack of internal
controls result in false or over-billings, or the Insurance company
lacks the controls to detect fraud, it's not our problem. All a payer
could be reasonably sure of is that the 837 claims indeed came from
Saint Therese Hospital, and that remittances, statuses and payments
actually are returned to Saint Therese Hospital.
Likewise, hospitals would be sure that whomever they sent 837s to really
was the payer they intended - as long as they used the correct ID to
obtain the CPP. Valid digital signatures of incoming claims would
indicate that the payer could trust the claim was coming from whom they
thought - not that they can necessarily trust the sending entity itself.
We can only guarantee identity on the Internet, not honesty or financial
robustness. Since we're going to use X.509 digital certificates to
buttress our trust model, we're dependent on the Trusted third-party
CAs (such as Verisign) to properly vet entities.
If out-of-network providers send standard transaction claims to a payer,
I would expect that electronic EOBs would be sent to the provider, and
that paper EOBs and a check would be sent to the patient. It only makes
sense to send payment to the patient, since in this case the payer only
has a contract with the patient - not the provider. Actually, you would
think that it would be prudent for the payer to always send some type of
paper EOB to the patient, in or out of network, to increase the odds
that funny business will be caught. Given the paper EOB, a patient
treated in-network might have an incentive to report provider
over-billing simply because it applies to his lifetime max.
I don't know how you could keep a provider from submitting an
out-of-network over-billing to the payer (which would only benefit the
patient since she receives the check). It's not my problem - I'm not
paid to worry about it. But standard electronic transactions don't
exacerbate the problem: these are probably also concerns when using the
old HCFA paper form for out-of-network claims.
So, much like the Public Trust model discussed in another thread, when
does one consider a business entity a trusted entity? How do you
determine whether or not payment is valid?
In the old days, when a patient was "Out of Network", the physician
simply billed the patient. It was the patients responsibility to
forward the claim to the payer (this is still used today, my dentists
bills this way). The payer then knows that the patient actually did
visit the physician and received the services. With the CPP, does this
become an automated process? What roll will the patient play, if any,
to ensure the claim is sent to the proper insurance plan for payment?
How does the Insurance Plan verify that the patient actually received
the billed services?
When using X12.58 security services, authentication and encryption are
done only at the Functional Group (GS/GE envelope) and Transaction Set
(ST/SE envelope) levels - the ISA is kept in the clear so intermediaries
know where to send the interchange. Note that X12.58 has NOT been
addressed in HIPAA at all. If accepted by the payer's translator that
would be great - but so far we can't assume either mandated use or
acceptance of X12.58.
EDIINT, on the other hand, *does* encrypt the entire EDI Interchange including the envelope headers (ISA/IEA) - when encryption security
services are applied. Since the routing of the EDI Interchange is
point-to-point through the Internet, and not via a VAN or Clearinghouse,
the sender/receiver ids are not used in routing so no intermediaries
(there are none!) need to see the ISA. By the time an EDIINT package
encrypts the interchange, it has already gone through all the rigmarole
Kepa proposes and has the final destination address available for the
SMTP routing or HTTP post.
Certification
Payers can require providers systems be certified. They can make this a
condition of participating in the payer's provider network. HIPAA doesn't
prohibit this. Requiring is also good business sense.
Your assumption that payers cannot require providers' systems to be
certified is just plain invalid.
This just serves to remind me that we need to discuss supporting HIPAA
transaction certification in the Healthcare CPP. I definitely think
certification can be of real value, but I guess I just want to ensure
that certification is not used as an excuse by payers to put even more
hurdles in the way of providers, causing unnecessary manual intervention
or creating onerous enrollment requirements. If certification
credentialization can be automated - i.e., the third-party certification
service could digitally "sign" the credentials in the party's CPP
(electronic trading partner profile), which could be examined
automatically - then I might be a lot less concerned. Remember:
eliminating all friction points which have to handled manually - with
pairwise negotiation - is one of our biggest problems to solve!
I would like to ask the folks writing the working paper describing the
Elements of a Healthcare Collaboration-Protocol Profile (CPP) - Marcelee
Jackson (who may not even know she was "volunteered" to work on this
since she was absent from the Friday, 08 March teleconference), Dave
Minch, Dick Brooks and Chris Feahr - to add certification credential
verification to their list of requirements.
I'm of the (perhaps minority) opinion that payers can't mandate
certification of providers: if a standard claim comes into a payer, I
can't help but think Administrative Simplification requires the payer to
take it into adjudication. Testing is obviously important (for anyone
with sense) - and I can see where not only does a payer want to ensure
all his systems are "go," but would like to be "certified" to cover his
"behind" in case a provider claims they tried to send standard
transactions which were rejected out-of-hand by him.
I don't expect providers have the same fear instilled - the worst that
will happen to them is to have non-compliant standard transactions
rejected, which they can then fix up and re-submit. It's not, like,
y'know, a payer is going to stand up and complain to the government that
this wretched little provider is screwing up in every way asking for his
money! Nobody says the health plan has to "debug" the provider's
non-compliant transactions: all the 997 has to do is report the first
X12 syntax error encountered and reject the entire transaction set, or
all the 824 (when we get one) has to do is report the first problem
inconsistent with HIPAA, and refuse the transaction. There should be no
back and forth "debugging" (on the phone), as long as the 997 and 824
are used correctly.
Certification. "Certification," as we use it in WEDI/SNIP, is
defined in the Testing ("Transaction Compliance and Certification")
whitepaper. It only "certifies" that an entity is capable of sending
(or receiving?) syntactically and semantically correct standard
transactions.
The second key issue is credentialing of trading partners. I don't think
we are intending the CPP to get into that territory. But just as smaller
payers now use services to assist them, there might develop more widespread
third party credentialing, for example, a signed certificate on the CPP or
other registry by a trusted third party that the entity is in fact a good
citizen doctor, licensed and all that. Such certificates are not guarantees
but certification that certain documentation was attested to, for which there
are fraud laws and other protections. I don't know, but I would not be
surprised if the credentialing now being done, except by larger payers, is
possibly a little lower quality than folks like to think. There may well be
room for improvement.
The note includes "nor have I tested to ensure your data". I believe
that third party transaction certification beats individual testing all to
pieces. That is the substance of my paper "ROI: Economics of Transaction
Certification", which I'll send to anyone who would like it. The idea is
that a trusted certificate by a professional firm is posted to a directory
for access by trading partners.
With regards to "Certification". "Certification" will not guarantee
that the transactions are not fraudulent, only that they are properly
formatted and contain valid content based on the standards. Not that
the content is appropriate for payment.
I have to agree with Rachel. Nothing in the regulation prohibits requiring
a trading partner to prove that he or she is capable of sending a compliant
transaction.
It was mentioned below that Payers are permitted to test with providers. We
view certification as an initial step in testing. If a provider cannot show
evidence of certification and we test with them, then past history shows
that we will spend a lot of time and effort to help the provider debug their
program. Our position is that the provider should offer some evidence that
they have a compliant transaction before we commit the resources necessary
to perform testing.
Also, keep in mind the current level and nature of dialogue between
providers and payers. Providers are very shrill in criticizing carriers for
claim payment processing -- even to the point that they are launching class
action lawsuits, filing complaints with regulators, and seeking new laws and
regulations. I suspect payers are going to want to insist that providers
are capable of sending truly compliant claims so that the money payers are
investing in becoming HIPAA compliant results in the efficiencies we are
seeking. Otherwise, if the transactions just result in more bad claims
coming in faster, it will exacerbate not reduce the current tensions.
Trading Partner Agreements
This maybe outside the scope of this group, but I need help understanding
TPA's between a payer and provider. I get VERY nervous when I hear folks
talking about providers entering into TPA's with payers because this process
can be incredibly labor intensive, drive down EDI transaction volume, drive
up the cost of EDI implementation and expand the time frame to implement.
From a provider perspective, if a provider chooses to contract with a
clearinghouse, the clearinghouse is its trading partner and will provide a
TPA defining requirements for exchanging transactions. The provider should
not have to enter into a proprietary individual TPA with every payer with
which it might ever need to exchange a transaction. This is of particular
concern because when these proprietary agreements are required, the cost of
managing the process is disproportionately assigned to the providers and
their clearinghouses.
So, off the soap box and to the question - Why would a TPA be entered into
between the payer and provider rather than between their third parties?
Our legal area is not on the same page with the people that say we can do
business without an agreement between the provider and the payer. In fact,
this is a topic that has had EXTENSIVE debate here. The reigning opinion
is that HIPAA will be forcing all payers toward agreements with the
provider, not eliminate them.
What I (and others) have been advocating here is that there is a need for
only two authorizations from the provider. One as a general trading partner
to cover legal and other issues for all transactions except the 835, and a
separate contact for authorization for the 835 (this does not necessarily
mean a hardcopy document). There are people (legal types mostly) that want
separate authorization for each transaction.
An initial authorization is necessary to start the relationship. That will
include an agreement and reference guide that identifies all items about
the payer that are allowed by section 1.1.1 of the HIPAA guides. At that
point, all of the HIPAA transactions to date except the 835 are provider
initiated. If the provider sends 837s, then the provider wants to do
claims. So, once the electronic relationship is setup, the use of the
transaction identifies the request to use the transaction.
The 835 is payer initiated, but only at the request of the provider. To
send it out automatically would not be appropriate. The provider can even
want the 835 without sending an 837, so we don't have any 'trigger' except
the provider's request for the 835. Since the 835 route to the provider is
not a given (it could be a bank that does dollars to data reconciliation
for the provider), only the provider can tell the payer where the 835
should be sent.
On the other hand, I do wish to point out that when the federal government,
most notably the Department of Defense, went full bore into EDI in the early
to mid 1990's they initially required that each supplier to the government
execute an EDI trading partner agreement. This was a huge failure and in
fact, became a major barrier for getting the hundreds of thousands of
suppliers willing to engage in EDI with the feds. Within 6 months the feds
abandoned the requirement for an EDI trading partner agreement. Other
industries also recognized the barrier an EDI trading partner agreement
became when trying to establish EDI information exchanges. So, I would just
urge health care to not rush into a business model that clearly didn't work
for other industries, including our beloved federal government, without
fully examining and understanding the impact and issues that will
result....this is a prime example of beware of unintended results!
I can vouch for Kepa's comment regarding many payers. We are a relatively
small Health System, but we have over 2000 payers in the insurance table of
our largest provider. Even if I assume that each company has at least 1
alias, that still leaves over 1000 profiles. That means if I want to send
directly to each payer, I need to negotiate 1000 TPAs, perform 1000 tests,
set up 1000 trading profiles, and implement however many unique transports
to deliver the claim payloads to the "first hop" recipients. And I'm just 1
provider (well, actually 15) -- think of how many of us are going to be
knocking at the payer's doors. Are you guys ready???
Then I shall simply pray a whole lot that if any one of the links in this
frighteningly fragile chain of mail carriers decides to change transports,
methods, passwords, encrypting, etc. that they give us good advance
notification, and that the information they communicate is accurate, and
that they don't decide to change things at the last minute..... Mess?? you
got that right!
Lets see....
If I can average 3TPAs per day, and get them all set up for testing it
should only take me 15 months to get all 1000 ready by 4/16/03. I guess I
can just make it if I start tomorrow... Does any of this sound as absurd to
anyone else as it does to me?????
"[if] HIPAA
will end up forcing agreements between each provider and its payers,
then the questions about who should be identified on the ISA becomes
moot." There would be no point in us spending our time figuring out
automated ways to share trading partner information (such as electronic
addresses) if paper TPAs were required: this information (the ISA
Identifiers and the electronic addresses) could just be placed on the
same (expensive) piece of paper.
The issue of Trading Partner Agreements arose in the Business Issues
Teleconference yesterday. Discussion led me to believe that it's still
unclear whether paper Trading Partner Agreements will be needed or
desirable under HIPAA. For background, you should definitely look at
the WEDi document "Trading Partner Agreements: A White Paper Describing
the Business Issues and Recommended Solutions Associated with Trading
Partner Agreements," by Doug Renshaw. It's available under
"Transactions Workgroup White Papers" at the WEDi/SNIP site at
http://snip.wedi.org/public/articles/Trading113000.pdf.
The topic came up because one of the callers wanted to know how - other
than by using a TPA - a sponsor (employer) would know whether to send to
the payer a full compilation of enrollees, vs. just the changes since
they last "talked." Other things a TPA might be required to resolve are
the situations (as in "situational") where data is expected or desired.
Fortunately, there seemed to be nothing in the discussion of a legal
nature - i.e., everything was technical, which means a mechanical or
electronic Trading Partner Agreement might suffice.
Besides these issues the caller brought up, I wanted to see what Doug
and his team came up with. His document is an excellent compendium of
the situations calling for agreement ahead of time. But, fortunately, I
saw nothing which could not be mechanized! Though he had the usual
stuff like specifying communication protocols, Clearinghouse
designations, and agreements on maximum numbers of claims (e.g., 5000
claims in the 837), he mentioned nothing that would require Lawyer Man
to get in the way of real business.
I probably can't emphasize enough how paper TPAs will gum up the works
in automated partner recruitment - to the point where our work in the
WEDi/SNIP ID & Routing Special Interest Group might be rendered moot.
What's the point of automated "discovery" of trading partner technical
requirements (communications and protocols) if that stuff may as well
travel with the paper TPA? Marcallee Jackson has confirmed that signed
paper TPAs would involve so much overhead that they "will cause the
labor costs associated with EDI enrollment to sky rocket." Rachel
Foerster has also related the story of the (bad) experience with TPAs
when required by the Federal Government.
Even though we have sub-projects for looking seriously at the ebXML CPP
(basically a mechanical Trading Partner Agreement or Profile) and the
838 - led by Dick Brooks and Dave Minch, resp. - I'm suggesting that we
move the concept of Electronic Trading Partner Agreements to the
front-burner. If we can mechanically represent in them everything Doug
has enumerated in the white paper, we'll be better prepared to fight the
conservative tendency to require paper TPAs.
Electronic Trading Partner Agreements fit into our scheme quite
elegantly, in that Kepa's DNS "directory" would be used to find a
trading partner's profile based on identifier. The profile itself would,
in addition to the stuff mentioned in the white paper, have the
technical routing information for interchanges. In effect, you'd be
"discovering" electronic trading partner agreements, not "inboxes,"
"portals," or "front doors."
EDI enrolment
Today providers who use a CH complete 3 - 5 TPA/Enrollment forms - Medicare,
Medicaid, BCBS and Champus are payers that almost always require agreements.
In my experience it takes an average of 2 - 3 weeks for a CH to receive
completed paperwork from the provider and an additional 6 - 8 weeks for
approval from the payer (though BCBS often approves in 2 - 3). It takes
providers as long to complete their part of the enrollment paper work for
these payers as it does for most to complete testing, implementation,
training and full production for payers who don't require it. That's if the
enrollment process goes well.
Many payers are very particular when it comes to their agreements. Some
require the signature of every physician in a group (imagine that if you
have 50+ physicians), most require a listing of every group number and
provider ID, some require social security numbers, some that the agreement
be sent in on a particular color of paper, others that only a particular
color of ink may be used and most will reject the agreement for any error.
Each agreement is proprietary. It often takes 2 or more attempts before the
provider gets it right. The whole process is an incredible hassle.
In other situations, the payer does not require a written agreement between
the provider and payer but does require the CH to obtain authorization.
This process, while still time consuming, is far easier than the one
described above.
I am strongly in support of TPA's combined with COT's and entered into only
by the parties directly exchanging data. It also seems that some sort of
power of attorney between the provider and CH should be sufficient to allow
the CH to auto-enroll its clients with the payer, particularly for the
simple exchange of data. More complicated data exchanges, such as EFT or
split routing, may require a more manual process but those exchanges are not
common today and not likely to be in the near future. I stress that the
vast majority of payers today do not require any TPA or enrollment process
between themselves and physicians who bill through a CH. These include
payers such as Aetna, Cigna, United Healthcare, Coventry Healthcare, Humana
and Prudential. I'd suggest we look at their current model and find ways to
keep it.
AFEHCT is very interested in this issue and I believe is also planning on a
work group.
1.
Electronic TPAs - machine readable documents that outline
information proprietary to the payer; e.g., information on routing and
information related to proprietary requirements for HIPAA transactions
(stuff that would normally be part of a companion guide).
2. EDI Enrollment - This is a process today that requires the provider
to sign an EDI agreement before exchanging transactions. This is a time
consuming process and a barrier to fuller utilization of EDI. It's of
particular concern to providers and clearinghouses since many health
plans seem to be planning on this same requirement which could
dramatically impact cost and timelines to implementation. Among other
payers, every Medicare intermediary requires this process today. The
primary question would be - is this legal post HIPAA? If yes, then the
second issue and third topic here would be:
3. An EDI Power of Attorney - This would allow a provider to assign
their clearinghouse power to enroll them with other trading partners
(clearinghouses, payers, etc) for the purpose of exchanging healthcare
transactions.
2.
But since then, Marcallee has
certainly convinced me that if the TPA "problem" cannot be gotten out of
the way, then automated trading partner "discovery" has less value. As
far as I know, we are the only WEDI/SNIP group worried about this
issue - the impediment of paper TPAs - at the moment.
If in their wisdom, the Business Issues SWG management finds it prudent
to create a new group concerned with ways to lubricate healthcare
e-commerce by eliminating or ameliorating the delays in trading imposed
by paper TPAs, we in the WEDi/SNIP ID & Routing SIG will defer to that
decision. In the meantime, I'm only too happy to see Dave and Marcallee
succeed in developing a Clearinghouse Power of Attorney or the "WEDI
Accord on TPAs" - if only to prove my good friend, Kepa Zubeldia, wrong
for once in his life!
We wanted to let you know that some progress is being made on the trading
partner agreement front concerning the legal ramifications of creation of an
entirely electronic eTPA. Yesterday William Kammerer, Marcallee Jackson,
and I held a conference call with 3 legal types from the law firm of Davis,
Wright, Tremaine (DWT), who have volunteered to provide some level of
assistance to us pro bono as we wrestle with the non-technical privacy,
security, and fraud-potential issues surrounding creation of an automated
eTPA.
The question posed to the teleconference group was "how can DWT work with
our WEDI-SNIP workgroup"?
We discussed our plans to move the industry toward an "electronic TPA"
rather than (in place of) signed paper agreements. The TPA we have
envisioned includes technical communication protocols, security and
encryption, and potentially even the "companion guide" type of information all of that being generally classified as the "technical" business
arrangement between the trading parties. Our most pressing concern is: even
if we can get all of the nuances of the "technical" business arrangement
included within our electronic definition, will there still be overriding
legal barriers which will still require each trading partner to negotiate
and sign a paper document to comply with the HIPAA regulations.
DWT explained how business agreements can be implied under the UCC. As a
simple example, when a customer sends an unsolicited order to a supplier,
and the supplier fills the order, there is an implied business agreement
under the UCC. DWT also indicated that there is now an extension to the UCC
which is being adopted in most states that specifically addresses electronic
business exchanges. After some discussion, their suggestion was that if we
could promote a health care industry-wide accord, that it could act as an
anchor point for creation of the compliance portion of the paperless
interchange agreement and would embody language which safeguards the
participants.
Our next steps will be to work with DWT in drafting a "talking paper" over
the next 3 weeks which lists some of the key elements that such an accord
would have, and how the accord would be used in conjunction with the UCC to
satisfy the regulatory needs (privacy/disclosure of PHI). Stay tuned...
Regarding your question: "what will a provider do to get transactions
to Highmark when he is fully HIPAA capable and doesn't want to pay the
freight (of a Clearinghouse)?"
We welcome providers or their billing agents to submit claims to us direct.
We assign them an EDI Trading Partner number (proprietary number) and give
them instructions on how to dial in to our EDI interface. This is how we
connect today; I am not advocating our process as the best mechanism for
the industry moving forward.
Requiring prior setup excludes the more occasional trading partner.
There are reasonable conditions in which a payer could agree to accept a
claim or other transaction from an infrequent provider, provided the
technical means for doing so is less hassle.
Q. What do you think about onerous EDI enrollment processes and
"certification"? Don't you want all these artificial barriers put up by
the payers removed?"
A: You can bet that I don't like it one bit. Remember, I have 16
different entities who send bills, and two entities who receive them.
Multiply 16 times the 500+ payers we correspond with and you can
understand the problem (technically, all entities don't deal with all of
the payers, but the subsets are large enough!).
Now the other side of my equation is that I receive claims (i & p) into
two of my entities (including receiving them from my own senders). As a
receiver, I have to ask myself, how much time do I want to spend dealing
with paper TPAs and cert testing before allowing a provider to send
x12s? The tradeoff is posting my CPP and letting claims flow in, and
reject any that aren't HIPAA compliant. Since my chosen software can do
a complete HIPAA check (similar to what our friends over at Claredi do),
I'm banking on the fact that i'll spend a whole lot less time in
auto-rejecting malformed batches/claims, and misdirected claims than if
I did the manual TPAs & testing. The one caveat is that i'd like to have
my TPs certify with an outside agency such as Claredi before they start
sending to me (less rejection processing if they get their act cleaned
up ahead of time). We should be able to incorporate a cert_id into the
CPP/A.
His point may be that since a known (or
participating) provider will have gone through a vetting process - and
signed all sorts of papers - that adding a few more pieces of paper
related to electronic claims submissions isn't that burdensome. Compare
this to Marcallee Jackson's comments from 23 January on EDI enrollment,
where she inveighs against the practice of having providers enter into
a "proprietary individual TPA with every payer with which it might ever
need to exchange a transaction."
Our whole project here is predicated on some assumptions: viz., that 1)
onerous setup and EDI enrollment is a real problem, 2) it can be
automated, and 3) the solution is secure. Even though it may not be a
critical factor - in that who wouldn't prefer an EDI enrollment process
that was automated, secure, and needless to say, inexpensive? - the
HIPAA law could be read in such a way that onerous (i.e., manual) EDI
enrollment is an impediment to Administrative Simplification. My
opinion is that if a payer would accept for processing a paper claim
(payable to either the provider or subscriber), it must take the
equivalent standard transaction set. And just as importantly, it must
provide a non-discriminatory "portal" for exchanging standard
transactions.
What we definitely wish to avoid, I believe, are onerous EDI enrollment
procedures, negotiated TPAs, and other sundry hurdles and hoops placed
in the way of providers who merely want to use the standard transaction
sets. Not only are these processes exceedingly manual, but they may
take months to consummate (per Marcallee Jackson) - surely an impediment
to frictionless e-commerce if there ever was one!
Doug Renshaw, of Highmark, said yesterday "We welcome providers or their
billing agents to submit claims to us direct. We assign them an EDI
Trading Partner number (proprietary number) and give them instructions
on how to dial in to our EDI interface. This is how we connect today."
Fortunately, he adds: "I am not advocating our process as the best
mechanism for the industry moving forward."
A common case will involve claims coming in from one of a payer's
participating providers who has never used EDI before. Remember, HIPAA
says you have to take their claim if presented in a standard electronic
format - and that presumably means without placing any onerous hoops to
jump through, such as TPAs, EDI enrollment, or waiting around for
payer-assigned IDs, logon IDs and passwords. Less common would be a
claim from a non-par provider, who wants to send a claim to be paid to
the patient (who does have a contract with the payer) - one with whom
the payer has absolutely no leverage and to whom the payer *must*
provide a means of submitting standard transactions electronically.
EFT
Re: Sharing financial information like routing codes and account
numbers. Providers who have set up debit blocks, as NACHA's Priscilla
Holland talked about, could safely place their account information in
the CPP; see "Electronic Funds Transfer and Security" at
http://www.mail-archive.com/routing@wedi.org/msg00570.html, Others
will probably have no choice but to use some kind of notation to
indicate where a payer could obtain that information, e.g., an e-mail
address or telephone number - necessarily involving a manual process.
Even if we had a fool-proof method of protecting the registry from read
access except by "vetted" participants, most people (providers) would
still feel uncomfortable sharing that information.
I don't know any way around that issue! Except if, as I suggested, the
837 were changed to include it so it could be sent directly from the
provider to the payer (encrypted or over a secure channel). A REF
segment, in the Pay-to or Billing Provider loop, can handle this. The
following says, in effect, bank account number 26000001538215 at
Fidelity Federal Bank & Trust of West Palm Beach, Florida (ABA No.
267087358):
REF*11*26000001538215**01:267087358~
Some people wouldn't even like that (i.e., the provider giving the EFT
information directly to the payer via the claim). Bruce T LeGrand, my
"Deep Throat" Blue contact, says:
My EDI portal is not secure. Since I support dial-up, NDM,
FTP, .. .. ..ad nauseam ad infinitum, my process is fairly
open. And I don't care. If a provider identifies himself to
me properly in a claim, there is no way anyone can spoof me
into sending the payment somewhere it is not supposed to go.
I verified that initially with him and that data is secure
within my system. If it comes in the claim, it can go
anywhere. This is not a secure network like the banks have,
and I don't see any reason why we should incur the costs of
that on top of everything else. When I move money, it will
be the bank portals that service that transaction.
Thanks very much for this information about the banking world... as
unsettling as it is. It may turn out that other CPP information about
payors and providers will have to be semi-restricted as well. I noticed,
for example, that some Claredi customers have chosen to restrict public
access to some of their directory fields, even though the information looks
pretty harmless to me. Of course, the whole point of our CPP record is to
make it widely available... but to one's potential partners... not
necessarily to one's "competition"... and maybe not very much of it in one
query, no matter who you are.
I would expect payments in most low-volume or CPP-initiated trading
relationships to continue to be paper checks for the next few years...
mailed to the address in the CPP record. In the hi-volume relationships,
it will probably be necessary to send a voided paper check, sign a few
forms, etc. in order to set up a direct-deposit, electronic payment
arrangement anyway. So all we may need in the CPP record now is a place to
indicate preferences/abilities with respect to electronic payments.
I think this settles the matter, though it's disappointing that banking
account "security" relies on keeping these identifiers semi-secret.
Perhaps we can accommodate protection of the financial account
information in the directory some technical way to ensure it is revealed
only to legitimate payers (insurance companies) - by restricting it to
only those folks who possess a directory entry themselves or somesuch
nonsense. Or the 837 claim could be changed to send the provider's
routing and account numbers for EFT payments directly to the payer (I
was surprised it wasn't there already), bypassing the Healthcare CPP
directory altogether.
CPP
CPP is a Collaboration Protocol Profile
CPA is a Collaboration Protocol Agreement
Companies define their E-Commerce capabilities and operational parameters in
a CPP. When two companies want to setup a trading relationship they exchange
CPP's. If there is a match in capabilities then the two parties agree to
form a CPA which describes how they've agreed to conduct E-business. A CPP
typically has contact information, EDI addresses/identifiers and other
information. I like to think of the CPA as the intersection between two
CPP's.
The CPP/CPA is all about the rules of electronic engagement between two
trading partners, with the CPP describing what you are capable of doing and
the CPA being an "agreement" between two entities regarding what they
**will** do.
For any who have attempted to wade through the CPP/A Specification (are
you listening, Chris Feahr?), it does seem daunting (at least to me).
But more likely than not, Dick and Dale will probably figure out some
way to use the CPP as a "template" just like what was done in the Open
Travel Alliance, where we "hang" our stuff off of it. Even if we just
use one or two parts from the CPP (such as the Delivery Channel stuff which is an XML'ized means of expressing Peter Barry's "EDI addresses"),
and design XML schemas for documents we refer to from the CPP, both of
our groups will have a "victory" that can fuel many a press release.
There is indeed "versioning" in the CPP - that for the CPP schema itself
(i.e., the version of the OASIS CPP specification), and for other
related OASIS specifications. But I'm not sure whether there's also a
capability to "version" the "instance" of the CPP, though. In any
event, it's a real requirement for us to have some mechanism to tell
whether the CPP electronic partner profile has changed at all.
I don't envy you reading all that OASIS stuff! I might warn you,
though: when you read up on the ebXML CPP, it looks big, ugly and
complex - and most of that stuff is irrelevant to traditional EDI.
Actually we might end up using only two or three things from the
existing CPP schema (e.g., Delivery Channel, Certificate Management,
Party Definition), and be off on our own devising a (general-purpose)
legacy EDI extension.
I would suggest putting aside the OASIS ebXML CPP specification. I
think it will only confuse us for now. We really need to build our own
requirements based on *our* needs - including everything we'd want to
see in a partner profile if we were starting from scratch. It can be
organized any way (UML diagram, spreadsheet, Access Database) that
floats your boat. Then we can take that list and give it to the OASIS
CPP/A group and let them help us to retrofit the existing CPP to allow
for "legacy" EDI extensions. We might have to "educate" the OASIS CPP/A
group on "legacy" EDI and Healthcare Transactions so they see just how
this old message-centric stuff works!
Dick Brooks and I joined the OASIS CPP/A group on a teleconference call
last Tuesday to apprise them of our status. I think we're on the same
wavelength, in that we agree much of our EDI partner profile stuff will
be in an XML document of our own schema design, XLINK'ed from the main
CPP. Our stuff will eventually turn into the OASIS ebXML "legacy" EDI
CPP extension schema. I may have forgotten to confirm with Dale Moberg,
Chair of the OASIS CPP/A Technical Committee, but I believe that
WEDI/SNIP is the first group in the world attempting to make ebXML work
with "legacy" EDI.
Given that HIPAA transactions are X12 only I would suggest that this group
elect to use a "file transfer" business process for exchanging HIPAA
transactions and avoid the complexities of the "deeper" business processes
(Claim/enrollment business processes within the CPP).
A lot of this security and certificate stuff is already in the ebXML
CPP, though I don't know how inextricably it's tied into the business
process or transport mechanisms - neither of which we'll probably be
using in our recommendations, unless we come up with a default "legacy"
EDI business process.
In the matrix Chris developed for the Elements of the
Healthcare Collaboration-Protocol Profile, please distinguish between
stuff which is native to ebXML (I suspect this includes certificate
handling) and that stuff which is completely new and not thought of by
the ebXML people. We'll have to have some organized manner, perhaps in
the form of a "subsidiary" schema, to give the OASIS ebXML Technical
Committee to show our new elements which pertain to Healthcare EDI.
Actually, is there any possibility that our "kind" of stuff (e.g., which
transactions are supported, with their start dates) is more properly
part of a Business Process rather than an ebXML CPP? If so, then we
might also have to "liase" with the UN/CEFACT ebTWG eBusiness Transition
Working Group, at http://www.ebtwg.org/ - providing yet another
opportunity for "volunteers" who are looking for work to do.
Funny you should mention that. This is exactly what we did in the Open
Travel Alliance B2B specification (http://www.opentravel.org/. I'm currently
working on an Energy Industry specification that *automates* trading partner
setup through the exchange of "profile documents"..
the CPP is simply an instrument to create the CPA which is the electronic equivalent of the trading partner agreement.
I would certainly agree with all of the payer comments regarding trade with
"unknowns", but the CPP exchange is our electronic (but certainly applies to
semi- or even non-electronic) equivalent to "discover" information about the
prospective trade partner. In my second paragraph of the "Conceptual
Schematic" paper I state:
"The data sets to be communicated should be comprehensive enough to allow
for a fully mechanized (no human) interaction, but the communication of such
information does not necessarily have to be in a single transaction. In
other words, exchange of all data necessary for loading trading partner
tables and initiating EDI trade can be in multiple exchanges. The first
exchange to identify and gather basic information, and a second and third
more secure exchange to provide sensitive information which is not meant for
display in a public setting."
I would further emphasize that if we assume for the moment that all data and
signatures needed to create a physical TPA can be "computerized", then the
CPP, even if printed out and snail-mailed back & forth can constitute
creation of a trade agreement. We definitely need to realize that most of us
will need transition time between the ultimate electronic future and where
we are today (which is with a file cabinet full of paper agreements). The
transition will be gradual as many people have observed, but we still have
to paint the target to shoot at.
I propose that we take the conceptual model that we are working out, and
apply it to a few real TPAs to fill the gaps. Then have all of you out
there with TPAs do the same. When we are done, we should have a pretty
comprehensive list of elements, and a pretty sound structure from which to
build.
In the future state, when a transaction arrives from an unknown, the
unknown's CPP can be accessed as a first step, and a CPP exchange can ensue
(whether automated or manual or somewhere in-between, as internal company
policies dictate). Through that process, the prospective trading partners
may discover that they really don't want to do EDI. That's OK. But the
legitimate providers & plans who do conform to the CPP standard & protocol even if in a manual process - will have a much simpler way of consummating
an agreement and beginning EDI.
History
Thanks. I stand corrected and also heartened to know that the X12 838 did
inform the work of the CPP/A effort. I remember the years (yes, years!) of
debate and rancor that the development of the 838 went through. It was one
of the most emotional and controversial efforts of X12 before Y2K hit us!
Dave did compile trading partner data attributes, and provided a
synopsis on the listserve. He was unable to really map to the 838,
which we needed to know so we could honestly say we considered the 838 we tried to eat our own EDI "dog food" and found it wanting! The matrix
Dave shows will probably be useful to you in devising your CPP elements
to describe partner capabilities.
Design
suggest that the CPP elements be designed
in a more general fashion. For example, instead of a number of
elements like "ExpectedTestDate837I," "ExpectedTestDate837P,"
"ExpectedTestDate837D" and "ExpectedTestDate270," perhaps an overloaded
"ExpectedTestDate" element might do the trick where the functional group
(e.g., 004010X098 for the 837P) is specified as an attribute or
subordinate element. This would better accommodate mechanical
processing of the XML elements in the CPP, and further, make our CPP
generally applicable to all "legacy" EDI as opposed to simply
Healthcare.
Until translators are CPP enabled - i.e,
they can update their trading partner tables with information from the
CPP which has been automatically "discovered" - the sender can manually
lookup the CPP and update his own trading partner files. I don't think
that's particularly onerous, and he can do it all by himself. Having it
automatically done by the translator is just icing on the cake.
Transaction Support
Every health plan, if it does electronic transactions at all, will be
required by HIPAA to support the 835 - both the Health care payment and
the remittance advice. So every payer, after H-Day, which uses the
Healthcare CPP and Registry (implying it is EDI capable) will have some
kind of notation in its CPP (electronic partner profile) saying it
supports not only both forms of the 835, but also all of the other HIPAA
standard transactions applicable to their business.
The more variable side is that of the provider: generally it's optional
for her to support the HIPAA standard transactions. She may support the
inbound 271 and outbound 270 and 837, but prefers paper remittances and
checks. It's problematical whether she really has to announce in her
CPP that she sends 837s: the payer will know that when it receives one
from her! But the payer does have to know which standard transactions
the provider can accept; silence on the 835 would imply she doesn't
support the 835 remittance. Now even though she doesn't take 835 EOBs,
the provider may very well want to be paid electronically through her
bank: our CPP extensions have to support some way of saying EFT
payments are accepted, specifying her bank routing code and account
number.
it seems to me after re-reading the 837i IG that while we can make
the recommendations regarding use of the GS for routing, this, also, is in
the domain of the quasi-automated TPA, and can easily be accommodated by the
CPP, even if the CPP for some payers ends up being a .txt file emailed to a
requesting provider (i'm not advocating that approach, just recognizing that
it will most likely be an evolutionary step toward the goal). Once the
provider receives the CPP, whether emailed or picked up from the payer's
registration, the next step may well be manual update of the trading partner
configuration in the provider's software.
Business Processes
I'll warn you, though, that there probably isn't too much in the CPP/A
specification that we can use directly "out of the box" - most of the
baggage in there is to support Business Processes and Messaging
Services, with nothing at all practically for "legacy" EDI support.
That's where we come in: as far as I know, we're the only folks who are
working to make the CPP support traditional EDI in a first-class way.
Except for the DeliveryChannel stuff in the CPP, you may be on your own
for defining partner capabilities as they apply to EDI.
I propose that we learn to walk first by defining a simple "file exchange"
business process that will allow organizations to exchange HIPAA compliant
transaction files (per one of my earlier e-mails). There is nothing to
prevent implementers from evolving their systems to become more integral
with actual business processes (e.g. real time enrollments) in the future,
but this is much more challenging achievement.
Any kind of "response timing" would probably apply at the transport
layer. Though some kind of service level agreement for application
transaction set processing would be nice - guaranteeing that real-time
270s are turned around with a 271 within 2 minutes, or that a claim will
be processed and definitively rejected or accepted within 24 hours - I
don't see the need for it right now to be specified in the CPP. I do
think it would be reasonable to have a specification which says TA1 and
997s will be returned in a certain period of time. But as long as
providers can query on the status of claims with the 276, or payers can
keep them "posted" with the unsolicited 277, application response timing
is overkill.
Application level things like "timeToPerform" in the ebXML CPP pertain
to Business Processes, but I really don't think we're going to be able
to apply more than the most rudimentary "default" business
process to primitive "legacy" EDI messaging. Actually, I really have no
problem with the way primitive "legacy" EDI works, including the HIPAA
standard transactions. But I'm still in the habit of saying "legacy"
because you look stupid - or just don't "get it" - if you fail to sneer
at EDI in front of Venture Capitalists!
Unfortunately, in a message centric system like the HIPAA standard
transactions, there's really no "Business Process" evident at the
interchange or transaction set level. See the thread entitled
"Requirements Gathering - Information Flows", especially my messages
from 02-16 and 03-01, at
http://www.mail-archive.com/routing%40wedi.org/msg00219.html and
http://www.mail-archive.com/routing@wedi.org/msg00283.html, resp.
If a Business Process exists - apparent at the level of interchanges it's solely that of sending an interchange and expecting a TA1 or 997 in
acknowledgement. You can't really say an 835 is expected in response to
an 837. I'm going to predict that our use of the CPP will probably
exercise very little of the ebXML Business Process stuff.
DeliveryChannels
The CPP people may not want to hear requests for supporting non-Internet
transport protocols or non-ebXML packaging techniques (e.g., EDIINT) I've kind of lost track of what's happening over there in OASIS, ever
since the onset of the "SHALL" - "MAY" battles. If they aren't
amenable to expanding the CPP, we just may have to go "off on another
tangent and re-create something else" - something more like IBM's tpaML
which was the progenitor of ebXML CPP - see
http://www.ibm.com/developerworks/library/tpaml.html.
I've "volunteered" Tim Collins to look into discovering the tons of
permutations "on a multitude of media, protocols, etc...", - including
the ugly stuff like modem settings and initialization strings, blah,
blah, blah. All that will have to be mechanically represented in some
type of XML file (or the 838) - or as an extension of the CPP
DeliveryChannel.
In that spirit, and in line with my e-mail yesterday, perhaps we should
start enumerating the various protocols that providers and payers are
likely to use (for describing EDI addresses in the "directory"). I
would be inclined to ignore the various legacy dial-up techniques, but
others may not be so inclined. And, obviously, someone who uses
expensive point-to-point leased lines doesn't need a "directory" because
they're already connected to the other party!
I would like to start off by suggesting simple old e-mail using S/MIME
attachments. It's bi-directional, and everyone can use it today - at
least as long as they're using standard e-mail clients like Outlook,
Outlook Express or Netscape Communicator - but not the non-standard AOL
play toy. The Microsoft-haters who use UNIX may have trouble with
standard ITU X.509 certificates, so we'll have to accommodate PGP
security. We should also provide for zipping (compressing) the EDI
before encryption, too. This minimalist technique accommodates both the
"disenfranchised" and the BIG PAYER (who can presumably automate his
side of things in a lights-out fashion). I can even see the little
"disenfranchised" doctor - the one who does his own electrical work cobbling together scripts to automate his e-mail client to do this, in
addition to coding up his own Javascript to build 837s and 270s (or to
parse 835s and 271s)!
I would add EDIINT into the mix, both the AS1 (SMTP e-mail) and AS2
(HTTP) varieties; the software is somewhat available, though probably
not affordable, for the "little" person. And FTP, too, even though the
"little" person might not have his own FTP server: he may have to poll
drop-boxes if he insists on using FTP on the receive side. I would also
leave a placeholder for ebXML Messaging Services, because that's the
"Next Big Thing" - and software vendors are falling all over each other
to provide practically free messaging service handlers (MSH).
The ebXML Messaging Specifications provide for a SOAP based packaging of
business payloads for direct point-to-point transfer over the Internet one of many packaging techniques that will have to be supported in the
WEDi/SNIP ID & Routing Specifications. Unfortunately, I would be remiss
if I didn't say it would take quite a while for ebXML Messaging Services
to catch on. Even though it can accommodate X12 EDI payloads, I doubt
seriously that there will be many implementations of ebXML MS within
Healthcare in the next couple of years, as new software would have to be
interjected into the software mix at both ends of the trading
relationship. We can expect Healthcare Clearinghouses and the more
prosaic forms of point-to-point transmissions (e.g., FTP, Kermit) to
predominate in the short term, and our "EDI Addresses" must support
these "legacy" transport channels.
Providers or their agents need to meet the payers half way. If the payers
make it clear in the CPP where a particular transaction is supposed to be
sent (and keep it updated), it is only fair that the providers follow the
bread crumbs and send transactions where the payers tell them to.
Ken has expressed one of the key reasons why different addresses for
different transactions are needed in the CPP -- in today's business
environment all of the transactions don't even go to the same place. In my
email earlier this week I indicated that there appear to be only 2 pieces of
information that are consistent throughout all of the insurance card copies
I have reviewed so far - and those are different addresses for claims and
eligibility inquiries. Often, the agent that responds to eligibility is not
even the same corporate entity as the payer. In fact, sending eligibility
inquiries to payers for certain plans wouldn't work in any event, because if
they are only providing the insurance shell and claims processing for a
self-insured employer, the payer may not even know where the appropriate
eligibility granting entity is... In fact, in that case, I would expect
that the agency that actually produces the insurance card (in this case, the
plan administrator) would be the entity that files the DNS & CPP entries.
So, bottom line, the CPP can and needs to be specific as to what
transactions go where, and the providers or their agents need to be at least
sophisticated enough to pick up the addresses and send things to the right
place.
We've discussed selecting alternate Delivery Channels based on
functional group (e.g., "real-time" 270 vs 837 batch), but I didn't
think Plan ID was ever considered as a selection criteria. That
wouldn't be impossible, I suppose. But consider the implications for a
VAN or other intermediary who would have no idea what Plan ID applied to
the transaction without drilling into the transaction set and looking at
application segments like the SBR in the 837. Besides, an 837 would
contain claims for multiple plans to be processed by a single payer or
TPA. I would suggest that we stay away from criteria for selecting
Delivery Channels which can only be obtained from the guts of the
application transaction set - or which could very well be non-unique
within an interchange.
Should we even waste time defining Delivery Channels (EDI Addresses) to
accommodate non-IP protocols? IP is going to take over the world,
anyway. See Michael C. Rawlins' exposé on ebXML, concluding with
"ebXML - The Road Ahead," at http://www.rawlinsecconsulting.com/ebXML/.
In it, Mike says:
"...IP was deliberately not specified because the TRP team wanted to
promote an open, 'protocol neutral' solution. But, at the very basic
level you can't achieve interoperability if you speak different network
protocols. This is an almost pathological pursuit of openness over
interoperability. That we didn't specify IP over the public Internet
should be an embarrassment to all of us who participated. UN/CEFACT and
OASIS need to bite the bullet and take a stand on this.
"If we care at all about interoperability, I see no excuse for failing
to specify some subset of HTTP, SMTP, and FTP as the approved protocols.
Only two would be best, but I could live with all three so long as some
comprehensive, coherent recommendations were made about appropriate uses
of the three. Again, we don't achieve interoperability if my application
talks ebXML over CORBA IIOP, and yours talks IBM's MQ Series or RPCs a
la RFC 1831. Even more to the point, SMEs and vendors of SME software
need some reasonable guidance about whether to support HTTP, SMTP, or
FTP, since cost-wise it may not be realistic to ask them to support all
three."
I haven't heard any articulation on this list thus far giving the
minimum set of protocols and packaging techniques we should accommodate
in our Healthcare CPP (Electronic Partner Profile). There are all sorts
of junk out there like dial-up Kermit, but is it fair to the authors of
the "Addresses and delivery channels" working paper (Dave Minch, Tim
Collins, and Dick Brooks) to speculate on what's actually used if nobody
takes the trouble to inform them of their requirements?
Hearing none, I would say we can safely concentrate on IP protocols like
FTP, SMTP and HTTP. The other "legacy" techniques could be accommodated
by some provision in the CPP Delivery Channel for describing them in a
textual format.
I made a concession towards proprietary IDs using the ZZ ISA
Qualifier: perhaps the CPP could specify an ID and qualifier (including
a ZZ mutually defined ID) to be placed in the ISA Receiver field if a
particular EDI Address (Delivery Channel) is selected. But no
proprietary IDs could be used to search the Healthcare CPP Registry, nor
is there a way to compel a sender to identify himself with a proprietary
ID.
HIPAA may well open the way for providers who haven't heretofore
submitted electronic claims to "discover" the CPPs (electronic Trading
Partner Profiles) of payers - which include EDI Addresses and perhaps
even machine readable "companion" documents. This is as close to
open-EDI as we'll probably see in the near term. Because of the
standardized implementation guides and code sets, it's conceivable that
partners could commence exchanging healthcare administrative standard
transaction sets with no (or minimal) bi-lateral agreement. The HIPAA
Implementation Guides really don't provide that much latitude for
"customization" - the clear intent (of Congress) is that every
healthcare player in the U.S. do the same thing consistently in order to
avoid that very "customization" which induces friction any time B2B
interoperability is attempted.
I don't think the ISA and GS sender IDs can be used for selecting
Delivery Channels for the simple reason it would be cumbersome to
enumerate every possible trading partner in the CPP. And besides, you
may not even know ahead of time who your trading partners will be! I
want our recommendations to exclude any unnecessary artifacts which give
payers an excuse to require providers to endure a cumbersome EDI
enrollment process.
But, anyway, I digress: the thing that made the biggest impression on
me was that NEHEN participants rely on a single means of communicating
with one another, viz. direct socket-to-socket TCP/IP network
transmission. Eliminating communications options vastly simplifies
things. This is obviously easier to do on a semi-proprietary network
between a few big players who can afford special software.
Peter Barry has suggested before that we need to specify "addresses" in
"three arenas": "dial-up (easy), Internet (easy), and private network
(not so easy)." He went on to describe the attributes of an address,
including "questions of media, packaging, security, and communications
capabilities. For example, a given address might have attributes to say
dial-in/login-script-X/security-A/ASCII-file-no-label/filename-path-sche
me-3, or something like that. Another might say
Internet/security-B/ebXML-scheme-1/etc."
What scares me if we don't limit the communications protocol
possibilities, is that we could end up with a spiraling list of
permutations. How do you describe - in a mechanical fashion - something
like "use Kermit over a direct dial-up connection to 8005551212"? Do
you also have to describe the modem mumbo-jumbo of 7-bit vs 8-bit and
even or odd parity? I vaguely recall that was the junk you had to worry
about when using pre-Internet BBSs or Compuserve.
Now that there's the Internet, I set my modem and dial-up connection
once, as specified by my ISP, and have forgotten about it, thankfully.
I now have a single digital dial-tone, which works for e-mail (secure or
insecure), file uploads and downloads, and surfing the Web. And when I
start getting fancy, like doing web services using SOAP, it's still the
same dial-tone: never again will I have to fuss with a modem unless I
change my entry ramp to the Information super-highway (moving to DSL or
cable, or changing ISPs). I hate modems and I hate printers.
Even Kepa hinted at all the possibilities his DNS "directory" will have
to handle, using examples like 8005551212.phone.hipaa.net and
kermit.8005551212.phone.hipaa.net, adding nonchalantly "[the] sky is the
limit. As long as we have some standard way to name them. We may need
to 'create' such a standard." That's exactly what I'm afraid of!
Let's assume for now that we'll be forced into supporting all the
"legacy" dial-up connection types - to assuage fears of the open
Internet's security "problems," what with some means of describing
scripts, logins, passwords, modem-settings, etc. etc. Then does anyone
know of any OASIS, W3C, IETF, etc. effort for devising XML files to
describe all communication capabilities of a partner? The ebXML
Collaboration Protocol Profile (CPP) specification only supports the
common internet protocols (and then, only if ebXML Messaging services is
used for packaging payloads - which could include HIPAA EDI). I want to
see something that says "this is a dial-up using Kermit with this phone
number." Surely someone has devised a schema for describing
communication capabilities. There's no sense in us reinventing the
wheel.
Versioning
that for most/many trading partners
accessing such a registry/repository doesn't necessarily have to be a
dynamic task performed each time an interchange is created. Rather, it might
be necessary to access such a registry/repository once or intermittently in
order to obtain the needed information for addressing/routing. Of course,
this assumes that the addressing/routing information is more static than
volatile. But, my gut tells me that it will be more static rather than
volatile....at least during the early months/years of HIPAA EDI deployment
I agree that it would not seem to be necessary to check the repository
info. very often. I was thinking, however, of including a "version
indicator" field somewhere (maybe just Active/Inactive flag, version date,
etc.) in the repository and possibly retaining several "expired" repository
versions in case the owner needed to roll back to or look at one of
them. But if the receiver wasn't yelling at the sender about something
going to the wrong portal and/or transactions were not being rejected, then
would there even be a reason for a sender to recheck this?
The other thing that occurred to me (I have approx. zero operational
experience with EDI.. so please bear with me!) is that commercial
translator systems must have some sort of configuration template/database
into which the prospective user will have to key all/most of this
repository data... sort of his local "EDI Address Book". Should we be
talking to translator vendors about how this info is managed locally by the
interchange senders? The obvious advantage of aligning our repository
structure with a standard local user's "address book" would be
auto-updating ability.
What you're referring to is the trading partner profile management function
that most good commercial EDI management systems provide. Some provide more
or less functionality than others.
Security
Should public encryption keys be available in this template?
IMO, yes. Along with other items needed to enable E-Commerce (e.g. self
signed certificates for SSL, public keys for encryption, public keys for
digital signature verification, Certificate Revocation List information).
CPA
I described the
CPA as being "... in the realm of science fiction. Theoretically, a
provider would introduce himself to the payer with his CPP, saying he
wanted to send claims electronically. Software at either end would
electronically negotiate terms, resulting in a CPA which binds the
provider and payer in a bi-lateral trading relationship."
The CPP's chief value appears to lie in the ability to use it to
automatically negotiate the CPA, after which the two trading partners
[previously unknown to each other] could launch right into a supported
TRANSACTION. Clearly, this completely automatic model won't work in
healthcare "out of the box", as you say.
believe there should be certain information that should only be
released until both parties can establish some level of trust. I
presume a large majority of trading partners will require some form of
testing, so all the testing information could be released without many
of the concerns regarding live data.
Once a valid test is completed, then it's possible that credentials
could be passed to the partner that will provide them information
regarding submitting live data. And in between the testing and live
data submission, processes could be performed to verify the validity of
the business entity, thereby giving the receiver and sender some level
of trust regarding the transactions.
I saw a thread recently that covered some method of establishing a
certificate based, trust relationship, that may help address this as
well. Using a PKI or PGP model, the ability to obtain information on
sending live data could be based on an entities ability to pass the
testing phase. A certificate or key would then be given to them that
would allow them to obtain the live data submission information.
At first I thought this could be out of scope for the group, but then I
realized we haven't created a strong enough definition of the overall
business processes in use today. I'm sure most receiver's will require
some form of testing, or some form of trusted certification that they
are compliant before simply allowing data to be sent.
So, the CPP must have the ability to define testing criteria and
requirements. Then, it should allow define the conditions in which
testing be by-passed if the sending party already has been certified by
so many other receivers.
I have not been too concerned with CPAs heretofore. CPAs, or
Collaboration Protocol Agreements, are in the realm of science fiction.
Theoretically, a provider would introduce himself to the payer with his
CPP, saying he wanted to send claims electronically. Software at either
end would electronically negotiate terms, resulting in a CPA which binds
the provider and payer in a bi-lateral trading relationship. I suppose
this is where Doug Renshaw could vet the provider, and give the provider
a user ID, password and proprietary provider ID - all automatically in
a matter of seconds. I'm not holding my breath waiting for this to
happen, though! Wouldn't it be much simpler for Doug to describe, in
his own CPP, an open portal for sending standard transactions to
Highmark?
Repository
The repository is the actual record of connectivity requirements and other
information that is needed to set up a trading relationship. Some of our
repository elements may be unique to healthcare or refer to a unique
requirement of HIPAA, but most will be data elements commonly required by
any 2 entities wishing to establish electronic data exchange.
The key points about the repository:
1. It is essentially one collection of data about one trading partner's
requirements, although it may be compartmentalized and it may be spread
over several linked "documents" or URLs
2. The repository remains under the direct control of the trading partner
to whom it refers (the "owner")
3. There is only one copy of the repository in existence
4. Each TP can decide what parts of his/her repository are exposed to whom
5. The repository can have any physical or logical location that is
acceptable to the owner
3. There is only one copy... -- this probably isn't needed as a statement
in the requirements, because it would tend to limit one's flexibility to
post a primary & alternate address (which can be provided for in the
registry), or for a Plan to contract with a CH to use their repository to
post a second copy. From a conceptual point of view, of course, you are
correct that the CPP itself isn't distributed across several repositories.
2. The repository remains under the direct control of the trading partner to
whom it refers ("the owner"). This statement would also tend to exclude
Business Associate relationships -- e.g. where an entity wants to contract
with a third party to use their services which may include posting a CPP for
them. I would add the term "or their contracted agent" at the end of the
sentence just to keep that door open.
The Healthcare Registry
The attributes and addresses in the CPP will exist someplace. Everyone
seems to forget that. If they exist in every participant for every trading
partner--that's a whole lot of maintenance. Very expensive, very error
prone, and discriminatory of the smaller players. Much better that each
participant can maintain its own information, publicly posted, such that one
change communicates to every trading partner.
But outfits are always merging and acquiring - and our registry
and Electronic Partner Profiles (CPP) can easily accommodate
these eventualities. There's really no need for cutover dates
(at the routing level), since the obsoleted ID can still be
searched on to either (1) produce a dummy CPP which in turn
points to the surviving entity's CPP, or (2) retrieve the
surviving entity's CPP directly (which contains the obsoleted
ID as a non-preferred search key).
I don't recall that we have ever had a discussion on "the merits and
demerits of using UDDI." Every time I've mentioned some kind of
"directory," whether Kepa's DNS "directory" (always in quotes 'cause
we've never given it a name) or the ebXML Registry, I have always
included UDDI in the mix.
I remarked to the OASIS ebXML Registry TC that I had some reservations
about UDDI's security: "Though UDDI remains a possibility for
discovering business partners' technical capabilities, its security (or
lack thereof) makes it somewhat problematical." That's the only
slightly pejorative statement I've ever made with respect to UDDI. See
http://lists.oasis-open.org/archives/regrep/200203/msg00038.html.
I have since been reassured by a correspondent that he "...can only
assume that you are referring to UDDI V1 and V2. The UDDI V3
specifications due to be completed in the next few months will introduce
more robust authentication, allow for authorization, and provide support
for digital signatures. I would be happy to provide more details as
needed. The discovery requirements that you have listed are exactly what
UDDI is designed to do."
As I said in my e-mail to the OASIS ebXML Registry TC, pretty much all
we want to do is store "pointers" to participants' CPPs (which reside as
XML files in their own servers), retrievable by one or more entity IDs.
For example, a Big Payer may well choose to be identified by their NAIC
company code. Providers, on the other hand, like hospitals, may prefer
to name themselves by any of a HIN, a D-U-N-S or a Federal Tax ID.
Likewise, a small practice may be identified solely by Tax ID, at least
until the National Provider ID is available.
Even if a small provider doesn't do standard HIPAA X12 transactions
himself (but rather uses a Clearinghouse or Billing service), he would
still have an entry in the Registry with a vestigial CPP (probably
resident in the ebXML Registry itself) which points to his respective
agent (e.g., via the ID of the clearinghouse or billing agent).
When the National Plan ID does comes into play, we would have multiple
levels of indirection in the retrieval: the plan ID would be used to
retrieve a pointer to the payer or Third Party Administrator (TPA),
which in turn would be used to access that entity's CPP for technical
trading partner information. Implementing search by Plan ID might be
more efficacious with the ebXML Registry rather than with Kepa's DNS
directory.
This should be a very simple use of the ebXML registry, and it allows us
to get some experience in the best ways to identify partners. We need
to get away from proprietary payer-assigned provider IDs in the context
of standard transactions, so as to level the playing field between
payers, providers and clearinghouses. The registry will also be a
test-bed for experimenting with various means of authenticating partners
(using X.509 certificates).
It might be too much to expect Dick Brooks to do the liaisoning with
both the OASIS ebXML Messaging and the Registry Technical Committees.
Does anyone here want to volunteer to develop Registry use cases
involving the discovery of WEDI/SNIP CPPs? It would be much more
appropriate for a "real" health care person to take on this role:
someone from either the payer, provider, or clearinghouse sectors needs
to step up to the bar on this effort if it is to provide anything that
will be acceptable to the user base and solve real problems.
It's only fair that the provider advertise her capabilities, just as the
payer would. The provider's "directory" entry would say she's willing
and able to take 835 electronic Remittance Advices. It could also have
a notation that said she was willing to take electronic funds transfer
at her bank, specifying an ABA routing code and her account number. Of
course, the payer doesn't have to do EFT (even if he does do the 835
ERA), so this is optional on the part of the payer - but paper checks
mailed to the billing provider are still always welcome!
The registry is a separate database, built to standard specifications, and
able to be accessed with a standard query protocol. It's purpose is to
link the all the possible identifiers used by a single trading partner with
his/her SINGLE repository ADDRESS (generally, a URL). For example, if
Company A is known by 10 nationally unique alphanumeric codes or names,
then he would probably want to have 10 different registry records, in which
each ID code points to the same repository, containing all of his "TPA"
information.
Key points about the registry:
1. The registry should conform strictly to an established standard (like
ebXML) so that it can be queried automatically using standard protocols.
2. An industry like healthcare can support any number of registries. There
might be a slight advantage in having only one registry for healthcare, but
it would be almost the same effort to have a system query 3 or 4 or even 20
registries in rapid succession. All we would be looking for in the
registry is the URL for the company's SINGLE repository record or
record-collection.
3. There is no limit to the number of different identifiers that can be
linked in a registry to a single CPP repository. This means that in
addition to the identifiers permitted in the ISA, we could list a company's
common names and abbreviations (e.g., "Vision Service Plan" or "VSP"), any
of the company's National PlanIDs, etc. Some standardization here would be
helpful and in general, we would expect the identifiers printed on the
subscriber ID card to be the same ones placed in the registry. There is no
requirement, however, to restrict the registry pointer IDs to the set of ID
codes that are "legal" in the ISA. ISA receiver ID preferences would be
spelled out in the CPP repository.
4. A company would be free to list itself in as many registries as it
liked. Companies should list the same identifiers in every registry, but
the system would still function OK if the different registries were not
perfectly synchronized... as long as the repository URL was listed
correctly in each record.
5. The registry would be a relatively static, low maintenance database. As
long as the listed entity kept the URL of its CPP Repository constant,
there would be no need to edit the pointers in the registry. The contents
and even the physical location of the repository could be changed whenever
necessary (by the owner), but it would only rarely be necessary to edit the
registry.
Ownership
I don't really think WEDI would agree to maintain a registry for HIPAA
covered entities. This is really a full time job. If the Government
were going to have the National Provider and Plan ID databases, maybe
the CPPs could be pointed to by them. But at this rate, I don't think
anyone is going to be seeing NPI and Plan ID databases any time soon!
So if we want a directory of Healthcare CPPs, it's going to have to be
either 1) Kepa's DNS directory, (2) the ebXML Registry, or (3) UDDI probably maintained by an organization that makes a living from this.
Frankly, I don't know how you build a business model around directories,
but there are enough vendors - and not just your chintzy pre-IPO B2B
startups, but real substantial outfits like IBM and Sun - tripping over
themselves to provide hosting, registry services and software. This is
why, as part of our "liaison" with the OASIS ebXML Registry TC, we're
also talking to vendors about an actual implementation. The same thing
can be done with UDDI, which Joe McVerry has volunteered to research for
the purposes of a Healthcare Registry.
I used to always call this Registry the "WEDI/SNIP" directory, really
only to develop a sense of "ownership" among the WEDI/SNIP ID & Routing
folks - in no way did I mean the WEDI Board of Directors has ever
approved of such an animal or would have WEDI run it. From now on, to
avoid confusion, we should just call it the "Healthcare" CPP directory.
Starting with the Patient
If we had any "discussion about how information is processed prior to
the lookup," it was solely in the context of the provider obtaining the
ID of the plan or payer (somehow - perhaps from the insurance card), or
the payer using the usually present Tax ID of the provider. We have to
make the assumption that some ID is available (to either provider or
payer, or their agents) for performing the initial lookup.
Once you have an ID, it should be clear sailing from there, even though
multi-stage lookups might have to be performed: e.g., if the provider
has the (future) National Plan ID in hand, he can look up the (1)
Electronic Partner Profile (CPP) for the plan, which in turn might be
nothing but a reference to the (2) Third Party Administrator or
insurer's CPP, and finally, the TPA's CPP might reference its (3)
Clearinghouse's CPP for the detailed Delivery Channel ("EDI Address")
attributes which define the actual transport method and port address.
I hope we don't have to understand, in detail, the "major models of
insurance" to describe a workable Registry and CPP system - except in
order to illustrate examples of how the thing works, as I just did above
(a model based on a self-insured plan handled by a TPA using a
Clearinghouse). In that example, we used the Plan ID to arrive at the
EDI portal at a CH to send claims or eligibility inquiries. The Plan ID
would still presumably appear in the application transaction set,
otherwise the TPA - which handles dozens or hundreds of self-insured
plans - would not know for whom the claim was intended.
Solving the problem of how to obtain the National Plan ID (or in today's
world, the payer and proprietary plan IDs) is out of scope for our
project. But it is a real problem, which Chris Feahr confirms. As I
indicated in my previous e-mail, it seems to have been solved adequately
in the Pharmacy world according to David Feinberg.
There is no doubt that the patient is "the weakest link" in this discovery
process. In vision care, when the patient is unsure of the payor/plan, we
routinely query one or two of the largest payors with both the patient's
and the presumed subscriber's SSN numbers... just because it's easy to do
and we often find them listed. An additional source of confusion in
identifying plans is the fact that the patient is often more aware of the
name of the general medical plan (possibly a closed-panel HMO that we do
not belong to). So the patient calls the eye doctor and states that she
has a "vision plan" through "HealthNet". We know that our office is not a
member of the HealthNet provider panel, but... avter investigation by my
staff, the "vision plan" turns out to be Vision Service Plan (VSP), meaning
that re really CAN see the patient after all.
The ONLY reliable info that you can get from the patient is WHO THE PATIENT
IS! A central patient plan-membership registry would be VERY
helpful. Otherwise, payors will want to essentially "SPAM" every payor in
the world with general "type 30" eligibility queries until they get a
"hit". The provider is in a tough spot here because many of these "unknown
payor" cases can be served in his office, but a few can ONLY be served
under the plan in an different office. Patients expect the doctor to
magically resolve this at the reception desk... before the services are
rendered. A good receptionist might remember that we have seen lots of
folks from that particular employer and "worry about who the payor is"
later (so as not to waste the appointment)... but occasionally, we get
stung and the patient is NEVER happy about having to pay for a bunch of
things that were supposed to be "free".
Searching and "Discovery"
But after thinking about it, maybe we will need to employ ebXML's robust
query technology: if there's nothing in the application transaction set
(e.g., the 270 or 837) that definitively gives the provider's "return"
EDI identifier, then perhaps the payer could use the ebXML Registry to
search on known identifiers (such as the TIN) to indirectly find the
provider's CPP, which in turn would have the preferred EDI identifier
(say, the D-U-N-S).
But until then, we're still left with problem of how a payer determines
the type (D-U-N-S, FEIN or HIN) and value of the ISA receiver ID for a
provider. Some of the more recent discussion has suggested taking an
identifier the provider is known by to the payer (e.g., the FEIN), and
using that ID to search the Registry for the provider's CPP, which in
turn contains the provider's preferred ISA ID (and that preferred ID may
be the FEIN itself, or another Tax ID, or one of the provider's D-U-N-S
numbers).
Keep in mind that if the Registry is powerful enough to be searched by
any (non-proprietary) ID, then the sender could just blindly stick the
FEIN in the ISA receiver ID, knowing full well that a VAN or CH
intermediary could search the Registry for the CPP which contains the
EDI addresses and ports. The whole concept of a "preferred" ID may give
way to a more powerful notion whereby a receiver can be identified in
the ISA by any of its known IDs (whose domains or type are allowed by
the HIPAA IG).
Regarding the discovery of the preferred "return path" to the small
provider, a payor could take the provider's FEIN from the individual
transaction (a 270, for example) and look up that provider's CPP... and
determine [for example] that he likes all his 271s sent to a CH maintained
by his OMS vendor, and his 835s sent to his bank.
if we
don't have a consistent way of addressing partners (based on IDs),
there's really no good way to do anything else, such as the lookup of
partners' information in a directory. And it's that directory (whether
a DNS lookup, ebXML Registry or UDDI) that contains the CPP which has
all the good stuff for automatic trading partner hook-up.
The solution has already been modeled: I'm suggesting - not the first
time, certainly - that a requirement of our specifications include the
ability to search the Healthcare Registry by any number and type of
identifiers. The illustration showed one possible means of how, in this
case, the Blue Cross Blue Shield Plan Code could be described and used
to locate the CPP (electronic Partner Profile) for the a particular Blue
entity (Anthem).
The BC/BS Plan code(s), along with any number of Tax IDs, D-U-N-S, NAIC
Company Codes, etc., etc., seem to be all perfectly acceptable keys to
use for arriving at (or "discovering") the same CPP - part of a general
requirement that has nothing to do with being "wedded" to any particular
type of identifier. We have not yet discussed how identifiers would be
qualified as search keys, and I was suggesting one possible means based
on X12 coded element qualifiers - in order to avoid re-inventing the
wheel. Other methods might involve the use of URNs (IETF Uniform
Resource Names), but that's getting a little afield for the time being.
To allay Ken Fody's concerns that "not all Plans want to use [the BCBS
plan code] on the standard transactions," let me emphasize that the
example showed "discovery" of Anthem's CPP based on any one of its plan
codes. Once the CPP is found, the junk inside the CPP would say where
to deliver transactions (the Delivery Channel) and the ISA receiver
qualifier and code to use. If Anthem were to prefer to have its NAIC
company code used as the Receiver ID, that's perfectly possible with the
requirements I've previously suggested in "Why do we flap our lips so
much about the ISA Receiver ID?," from 12 April, at
http://www.mail-archive.com/routing%40wedi.org/msg00438.html.
I have a tendency to write in prose, as if describing a system that
already works - when in fact we all know we haven't written the specs
yet! But I fancy that I'm setting forth the "Grand Vision," and
(preferably) someone else is busy compiling my musings as a set of
requirements within the respective Working Paper groups. Is it working?
I'm not trying to shove anything down anyone's throat, but y'know:
searching on various identifiers to "discover" CPPs does seem to be
something people can use - and the ebXML Registry already supports this.
A correspondent has confirmed that the most powerful ID for identifying
BC/BS entities is the Plan Code. He said it was used in several
inter-plan claims exchange systems and is universally used by all Blue
plans on membership cards. Which is true enough, considering my own
Anthem card shows plan codes of 332/834 (Institutional vs. Professional)
on the front.
Now it seems reasonable that my doctor ("shorthand" for saying his
staff, software, billing agent or Clearinghouse - let's not get pedantic
here) could take the "834" and look up Anthem's electronic Partner
Profile (CPP) in the Healthcare Registry to see where to send claims or
eligibility inquiries.
Obviously, "834" by itself doesn't mean much - it has to be qualified by
some code to say that it is a Blue Cross Blue Shield Association Plan
Code (in both the CPP and the Registry search key). The first place to
look for such qualifiers would be the X12 ISA Interchange ID Qualifier even though the BC/BS Plan Code is obviously not a HIPAA compliant ISA
receiver ID. Such an animal doesn't appear there, but D.E. 66 Identification Code Qualifier - used in the NM1 does have code value AD
meaning "Blue Cross Blue Shield Association Plan Code."
So the Registry search key could be shown (stylized) as something like
66:AD:834 (meaning D.E. 66 code value AD qualifies value 834) which
could be used to locate Anthem's CPP (assuming Anthem placed a list of
all their associated plan codes in their CPP: 160 and 660 for Kentucky,
130 and 630 for Indiana, and 332 and 834 for Ohio). There's no reason
the Healthcare CPP parts which specify Delivery Channels could not
account for all plans using the same or different EDI portals, depending
on Anthem's preferences. I'll leave the details for defining this stuff
in the CPP to the volunteers who are authoring the "Elements of the
Healthcare CPP" working paper (Marcelee Jackson, Dave Minch, Dick Brooks
and Chris Feahr).
I would
also add an additional concept/idea that surfaced this week during
discussions at X12 in Minneapolis, i.e., that for most/many trading partners
accessing such a registry/repository doesn't necessarily have to be a
dynamic task performed each time an interchange is created. Rather, it might
be necessary to access such a registry/repository once or intermittently in
order to obtain the needed information for addressing/routing. Of course,
this assumes that the addressing/routing information is more static than
volatile. But, my gut tells me that it will be more static rather than
volatile....at least during the early months/years of HIPAA EDI deployment.
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.
Actually, the ISA receiver ID would generally *not* be the key into the
Healthcare CPP (Electronic Trading Partner Profile) Registry, for the
simple reason you would not know what to use as the ISA Receiver ID
until you had obtained the CPP for the recipient - which in turn tells
you which ID to use!
Imagine this scenario: a provider wants to send a claim to Big
Insurance Co. She knows *some* payer ID either by (1) serendipity,
e.g., she remembers the NAIC for Big Insurance Co., or (2) obtaining it
indirectly through the particular National Plan ID (*future* - remember
National Plan ID hasn't yet been implemented or funded) which appears on
the patient's insurance card, or (3) obtaining the EDI ID (in this case,
the NAIC) directly from the insurance card.
Either the NAIC company code or the National Plan ID could be used to
search the Healthcare CPP Registry (notice I no longer call it the
"WEDi/SNIP" Registry!) to obtain Big Insurance Co.'s CPP. The CPP then
contains the EDI Addresses to be used (depending on criteria such as
Functional Group ID) and the EDI ID to be used in the ISA Receiver field
(in this case, Big Insurance Co. prefers - or mandates - the NAIC). The
provider must use the Receiver ID specified in the CPP, because the EDI
Address to which the interchange is sent could very well be a VAN or
Clearinghouse that only knows the payer by the NAIC.
Or perhaps the Clearinghouse only knows the payer by some *contrived*
(CH-assigned) receiver ID - neither the NAIC nor the HCFA carrier code
or any other standard ID. In this case, the selected EDI Address in the
CPP would say which qualifier and ID to use in the ISA receiver field
(and it could be a ZZ "mutually-defined" ID). I want to emphasize I am
not back-peddling on my abhorrence of the ZZ here: the "mutually
defined" ID is not being used as a *key* into the Healthcare CPP
Registry (it can't be, because the provider wouldn't know it ahead of
time). The EDI Address in the CPP is simply saying the provider has to
stick in this qualifier (ZZ) and an arbitrary receiver ID into the ISA
before sending the interchange.
It works the same way when the payer wants to send an application
message to the provider. And remember, standard transactions from the
payer can be unsolicited: paper claims could result in electronic 835
EOBs! The payer might only have the FEIN (Tax ID) of the provider
available. He uses the FEIN to search the Healthcare CPP Registry to
locate the provider's CPP. The provider has said she accepts 835 EOBs
at a particular EDI Address. Perhaps she is to be identified in the
ISA receiver ID with her D-U-N-S, with a specification in the EDI
Address that says the transaction set must be encrypted using X12.58 and
sent through a VAN (since VANs are not covered entities generally, PHI
has to be hidden from them using encryption). This illustrates the
situation where a FEIN is used as a key into the Healthcare CPP
Registry, but the D-U-N-S is the ISA Receiver ID. Again, the ISA
Receiver ID was not used as the key - it wasn't even known until the CPP
was obtained!
Or maybe the provider uses a Clearinghouse, and her CPP EDI Address has
said 835 EOBs (or even all transactions) go to the Clearinghouse, using
a CH-assigned ID in the receiver field. In this case, a FEIN was used
as the key into the CPP Registry, but the ISA receiver ID is a
ZZ-qualified CH-assigned provider ID. Since the provider is a customer
of the CH, she knows ahead of time what her proprietary CH-assigned
receiver ID is, and can place it in the EDI Address so senders know what
to use in the ISA.
If it seems I'm softening on the ZZ qualifier, I'm not. Consider the
first scenario again, where the provider has "discovered" Big Insurance
Co. in the CPP Registry. In this case, the EDI Address for claims says
to send the 837 to a clearinghouse. It's perfectly okay for Big
Insurance Co. to say in the EDI Address within its own CPP that a ZZ
qualified receiver ID be used in the ISA - after all, Big Insurance Co.
is a customer of the Clearinghouse and has long known its contrived
CH-assigned payer ID. But there is no way to tell the provider she must
use a CH-assigned sender ID - she's not even a customer of the
Clearinghouse, and this may be the first time she's ever sent anything
through that Clearinghouse. It would be mighty presumptuous of the CH
to insist that the non-customer provider identify herself by a
proprietary CH-assigned provider ID - as if it could even be done
technically.
Chris Feahr brought up the possibility of VANs and CHs sharing their
"family jewels" - their directories. That's unlikely: the best we can
hope for is for them to populate our directory with their payers, with
pointers into themselves! But I would think it very improbable that CHs
would give away the names and IDs of the providers they service.
Visibility
Yes, I was disappointed at the reticence of most of Claredi's directory
participants to share their information. Most of it's locked down and
available only to other members of their trading "group." Obviously,
the main purpose of the Claredi directory is to share information on
certification progress: perhaps folks are humbled that they are not
further along in achieving compliance, and don't want the rest of the
world to know! I guess that's only natural.
In any case, as Chris notes, the same "shyness" will affect our
Healthcare CPP Registry. If people are not too keen on even publicizing
their address and phone number, they probably won't give away to just
anyone as to how to send transactions their way. Even though I'm
absolutely confident we can come up with technological solutions to
expose information only to others in certain categories, that still will
not get people over their agoraphobia. This is a social engineering
problem that mere technology will not solve.
On the positive side, clearinghouses are always anxious to advertise the
payers they support - I suppose that's a selling point to providers. So
at least CHs will probably be happy to prime the pump with payer CPPs which will naturally point to portals at those very same clearinghouses!
Keep in mind that the CPP (electronic partner profile) is really not
dependent on a global, public federated registry. These are just
standardized XML documents with machine readable information that
describe the partner's capabilities: certification, financial
institution data and EDI addresses, inter alia. The CPP doesn't have to
reside in a public directory. A payer could continue to do business the
old way, where a provider has to fill out all sorts of paperwork, sign
TPAs, endure hideous EDI enrollment delays and whatnot. And at the end
of all this, he'd be e-mailed - what else? - a nice CPP!
If payers were the least bit reticent about sharing their companion
guide information on the Internet as part of the WEDi/SNIP CPP
(Electronic Trading Partner Profile), that would put a crimp in our
efforts to automate "discovery" of trading partners and their technical
requirements. Can anyone enlighten me as to what one might consider
"confidential" in a companion guide? And if such proprietary
information exists in there, is there the possibility that it, ....well,
has no business being there in the first place?
Proof of Concept
Registry
Thanks to Lisa Carnahan for tracking the list, and especially for
writing in! There's certainly no need for me to speak up, because Lisa
hasn't mis-characterized anything we've talked about! But as you know,
I'm not one to resist writing in. Indeed, we're thrilled to have NIST
take an interest in our modest effort to design a Healthcare CPP
Electronic Partner Profile Registry, and I join Rachel in
enthusiastically welcoming NIST as an active partner in the WEDI/SNIP ID
& Routing Group.
I want to add that NIST - the National Institute of Standards and
Technology (part of the U.S. Commerce Department) - will find that
Healthcare administration has perhaps more interesting needs than other
verticals, simply because we have so many possible identifiers which
would be used to key into the registry. This should make a prototype of
the Healthcare CPP Registry a more valuable testbed for evaluating
capabilities in the real world.
A number of Registry vendors have graciously offered their products and
services in assisting us in developing a prototype. But I think having
NIST help us in conducting a field trial adds a panache of integrity and
objectivity to our evaluation. And it goes without saying that if we
can pull off a successful prototype together, having the NIST imprimatur
will go a long ways toward influencing WEDI/SNIP and AFEHCT - to say
nothing of CMS - to formally adopt our recommendations.
CPP
don't want to get people too concerned that they're going to have to
wait for "smarter" auto-reconfigurable software before they'll get to
see the benefits of electronic Trading Partner Agreements. As a proof
of concept, I see us developing XSLT style-sheets for displaying e-TPAs
that have been "discovered" via Kepa's DNS "directory." Since it's
starting to look like our e-TPAs are probably going to be XML documents,
XSLT style-sheets can render them in a human readable fashion on your
web browser. In my crystal ball, I predict we'll have some "volunteers"
develop these XSLT style-sheets for contribution as non-normative
material for our work product.
All the standard trading partner setup information you'll need including communications protocols, URLs, EDI contact addresses,
"companion" document information (e.g., explanation of situational
elements), supported transactions, security and acknowledgement
requirements, etc. - will be available simply by providing an identifier
(like a NAIC or DUNS) of your trading partner. So even if you have to
copy and paste information from your web browser into your existing
communication and translation software, it will sure beat paper
documentation! And it will be in a consistent format, regardless of
trading partner.
In short, you don't really have to wait around for Dick's
"next-generation" auto-configurable ebXML software before you start to
see the benefits of the WEDi/SNIP e-TPA!