AND THE INTERNET
A look at
the reimbursement life cycle provides a case study for some of the issues
facing modern healthcare entities. On the surface, the issues seem simple:
Patients are covered by payors, either through individual insurance plans
or through their employer-sponsored group plans. Providers render services
to the patients, and in turn the providers want to get paid for the services
they have rendered.
However, as anyone who has ever had a claim go awry knows, there are literally
hundreds of things that can get in the way of a smooth process.
Some common issues:
Is the patient covered for the services rendered?
Completeness: Is all of the data required by the payor provided in
the required format?
of benefits: Should someone else be paying for some or all of the
Authorization: Does this service require pre-approval?
review: Are the services medically necessary in the opinion of the
provider side, this situation creates an administrative nightmare. A reasonably
sized physician practice will have to deal with literally dozens of payors;
a large hospital will count scores or even hundreds. With no single point
of information, providers spend significant amounts of their administrative
budget trying to get paid (estimates suggest that 35%-45% of all administrative
efforts is 'wasted' in chasing payor issues).
payor side, administrative overhead associated with member/provider services
would seem to cry out for change as well. Despite significant advances
in IVR systems and self-service Web portals, payors still spend heavily
on clerical and administrative support. The complexity of rules created
by payors coupled with a
lack of sophistication on the part of many providers and consumers means
that a significant percentage of issues are still resolved via costly
of the above, so the argument goes, payors should be chomping at the
bit to expose their business rules and processes to providers and consumers
via the Web Services-enabled gateways. Providers should be able to go
to a single terminal, type in a few key pieces of identifying information
about a patient, or better yet, swipe a card, and viola - instant eligibility
lookups, pre-authorization, dispute resolutions, and so on.
suggests that widespread adoption of Web-Services in the reimbursement
cycle faces significant hurdles. The industry has a long history of false-steps
in the direction of open, standard-based initiatives. Consider most recently
the case of MEDUNITE. With the significant financial backing of seven
of the largest national payors (including Aetna and Cigna), MedUnite was
launched in late 2000 with the
aim of providing a single point of entry for providers interacting with
the payors. Better still, it was based on an open access policy, encouraging
other payors beyond the founders to participate. Yet, by the summer of
2002, three of the original seven payors had publicly stepped back from
their commitments, and the rest seem noticeably non-committal on their
continued support of MedUnite. It is unclear at
this point what the future holds for MedUnite, and the same is true of
many other initiatives that have attempted to solve the problem outside
of traditional EDI Channels.
the obstacles facing widespread adoption of Web Services have more to
do with fiscal and political realities and less to do with technology.
Consider for example:
financial straits of many provider organizations, with IT budgets squeezed
by ever-lower reimbursements. With little funding that is available is
focused on sustaining existing operations.
demands on payors to service their sales channels, either through
better interfaces to brokers or directly to individual and group customers.
this demutialization, mergers and acquisitions, and other top-level issues,
and the CIO faces a host of competing big-ticket initiatives.
in the claims clearinghouse area, with WebMD and NDC, for example, needing
full cooperation from a significant percentage of the payor population
in order to make Web Services a viable backbone (note that NDC was one
of the original supporters of MedUnite).
resources in all areas still being deployed to meet the near-term demands
of HIPAA compliance.
hurdles, INAM believes that Web Services have the potential to significantly
impact the patient/payor/provider interface. Unlike the dot.com frenzy
of the mid and late 90s, adoption of Web Services will likely be led by
established industry heavyweights. The potential competitive advantage
this will yield in terms
of administrative cost savings is great enough to warrant investments
in the near term.
As many articles
have predicted, we agree that Web Services deployments will
begin behind the firewall (in some cases work is already in progress).
Also, as widely reported, once HIPAA - compliant transactions are universally
adopted, the last major technical obstacle will have been eliminated.
Therefore, it makes sense for organizations to be 'Web Service-enabled'
so that when/if there is critical mass prepared to expose Web Services
outside the firewall they will be ready.
examples by industry segments include:
Should begin implementing Web Services as part of a coordinated middleware
strategy based on ANSI x12 standard formats specified within HIPAA guidelines.
A logical first step is converting selected components of existing portals/self-service
websites to utilize Web Services.
and Consolidators: Ensure that existing EDI interfaces are abstracted
and enhanced to build on a backbone of WebServices. Given significant
efforts already allocated to HIPAA compliance in these organizations,
the foundations are already in place.
Management and Hospital Accounting/Billing Systems Vendors: With the wide
variation in quality AND sophistication of architectures in these systems,
this is likely an area where a select few vendors will be able to stand
out from the pack. Those systems with relatively open architectures need
to begin looking at Web Services by building modules that will allow them
to activate a 'direct connect' service either via clearinghouses or, more
intriguingly, directly with payors.
of an implementation approach, we believe that all major players regardless
of the type of organization should begin pilot projects as soon as possible.
A typical roadmap would include:
assessment: Covering existing applications architecture, processes
and people, and, perhaps most significantly, quality of business rules
(e.g. edits) in existing applications.
identification: Identify on or two manageable projects that at minimum
meet the following criteria:
Solve a real problem in order to generate internal buy-in
Can be executed in 4-6 months
Span at least two major internal systems
focus on building a middleware strategy that will support multiple interface
mechanisms, including traditional EDI and Web Services,
Aside from normal best practices, ensure that special focus is placed
on performance testing and security.
Even if the
conditions do not develop to support the Utopian environment envisioned
by some technology prognosticators, the work done today will certainly
support many initiatives, whether point-to-point solutions between specific
partners or broader, industry-wide initiatives. As is often the case with
bleeding-edge technologies, the ultimate product may not be exactly as
envisioned today. However, given the potential, smart CIO's will make
incremental investments today to ensure the organization is not suddenly
left behind if the best-case scenario does in fact evolve.