Thomas,
This is interesting... I had not given much thought to the importance of
implementation experience feedback. It never occurred to me to consider
it *part* of standards development process...although, it seems rather
obvious now that you have pointed it out. My own experience is actually
quite strange and somewhat unlikely, having been so concentrated on the
planning aspects of application development for the last 7 years,
without having ever built a real application! Because of my
"human-relationship" orientation to the problems that drove me into the
software world in the first place, I've been almost more focused on the
fairness and equity issues surrounding standards development than on the
deployment of an actual application. I thought we just needed a better
standards develomnent machine.
Here are a few highlights from my strange, 4-year odyssey, in search of
the Holy Standard...
I gained an excruciatingly detailed understanding of healthcare business
processes from 20+ years of attempting to practice optometry in
Information Hell. The driver to finally "learn about application
development" in late 1996 was the realization that I was probably going
to have to build the component that was obviously missing... and that
none of my trading partners apparently had any interest in building for
me: some kind of internet-based "hub" that would allow any doctor to
have efficient business connectivity to all desired trading partners and
point-of-sale access to increasingly complex information about an
expanding universe of 50,000 eyewear products.
The need to "learn about standards development", however, came 3 years
later, along with the realization that the uniquely unbalanced,
competitive dynamics of our corner of the healthcare jungle were NEVER
going to allow ANYONE'S proprietary, industry-wide communication
paradigm to even function, let alone resolve a significant part of the
doctors IT-headaches. The browser-based garbage that was being foisted
on to doctors in the name of "technology" was actually increasing my
labor costs, in comparison to handwritten paper forms!
So I abandoned the design work on the 'hub" concept, which by then had
become a [model of] a full-fledged ASP practice management system on the
doctor's end. Clearly, a reliable standard was going to be needed to
give any investor the confidence to fund something this complex... for
such a small market. It seemed to be either that, however, or the
entire industry would have to "surrender" to one of the dozen or so
proprietary models attempting to cash in on dot-com-fever. Or the
industry would have to agree on a standard.
So in late 1999, I took up my machete and embarked on a mission to find
the part of the jungle where the standards I needed were being cooked
up. Buoyed by the Utopian promise of the HIPAA Transaction Rule, I was
determined to create some kind of acceptable "open standards floor" in
the vision industry... come hell or high water. The HIPAA rule seemed
to say that providers had the right to such a standard (for at least the
insurance part of my headache) and payers were under a federal mandate
to implement it. Unfortunately, no one in the vision industry had heard
of HIPAA!
Of course, as soon as I figured out how to read an X12 implementation
guide, it became obvious that the HIPAA transactions were hopelessly
"broken" for eyeglass plans... causing me to spend the next 2 years
getting X12, HL7, the feds, and the vision industry to understand and
eventually acknowledge that fact. The most intractable HIPAA EDI
problems for the vision industry are still clustered around terminology
issues with frame and lens products... that the manufacturers and labs
had not been able to resolve, despite 19 years of meetings... largely
because they lacked the technical leadership and arcane knowledge that
only seemed to exist in the parallel universe of Standards Land.
In early 2001, I finally persuaded our largest payers, the AOA, and a
few PMS vendors to undertake a series of meetings with HIPAA officials
to determine what could be done, at least about the eyeglass claim
problem. (by that time, the greater provider community had pretty much
given up hope for eligibility queries and payment advice. The looming
deadline had focused nearly everyone on the "money transaction",
claims). That's when I became engulfed in the next layer of
intractable, small provider problems around HIPAA: Routing, addressing,
and identifier issues. Even if a provider managed to cobble together an
"837" claim, how was he supposed to get it to the payer?? And how would
a payer (or anyone) fling anything (like an acknowledgement or error
message, for example) back to the provider?? Ooops!
After a 6 months of work in the WEDI "routing and identifiers" group, I
discovered the final nail in the HIPAA-EDI-coffin: apparently, there
was no standard way to represent the convoluted situational logic in the
HIPAA imp. guides... in an unambiguous or computer-understandable form!
Great! By then, the entire HIPAA implementation community had
unanimously endorsed the Anal Retentive Theory of "HIPAA compliance"...
meaning that all "required" elements HAD to be populated in EVERY
transaction. If a data element was marked "situational", and the
situation was true, then that sucker was REQUIRED! "Accepting and
processing" a transaction with even one "required" element missing,
would cause both scofflaw trading partners to be immediately shackled
and hauled to HIPAA-jail!
The "conformance nightmare" sparked a very heated, summer-long slugfest
on the WEDI listserves last year and even spawned a whole new non-profit
organization called HCCO. The core problem was that every
translator/validator vendor had essentially cooked up his own way of
coding the IG-logic into his EDI tools... and some had sorta glossed
over (and occasionally misunderstood) the situational logic, described
only in plain English in the .PDF versions of the IGs. (The "table
data" form expresses only the base standard... none of the logic in the
modified IG that was stipulated in the Rule). In fact, an X12 committee
started combing through all the HIPAA guides around that time and
documented hundreds of examples of inconsistent use of the X12 data
element dictionary terms (because separate committees had worked on each
transaction and the DED itself, was hopelessly non-normalized). Some of
the situational requirements were ambiguous and a few were
self-contradictory!
Bottom line is that by the time the industry had gotten itself to the
point of EDI testing, no two validator engines could agree whether test
files were "hipaa compliant" or not. In accordance with the Anal
Retentive Theory of HIPAA Compliance, however, payers had all programmed
their inbound claim "edits" to be in absolute conformance to what THEIR
OWN translator/validator considered to be "HIPAA compliant". That's
when we started hearing the train whistles in the distance... here is a
site one of my co-conspirators erected to explain the "HIPAA Train
Wreck", if you are interested:
http://www.aptigroup.com/TrainWreck/index.htm ... only 10 weeks to go!
The Other HIPAA
In early May, I published my "dead parrot" letter to the industry,
suggesting that EDI for 400,000 providers was as bereft of life as John
Cleese's Norwegian Blue... and that we should declare it so and move on.
President Bush's ambitious E-Gov initiative includes the Consolidated
Health Informatics (CHI) initiative that makes the HIPAA Transaction
Rule look puny by comparison... and HL7 has been clearly designated as
the lead SDO for CHI. While people still prefer not to talk about
"starting over" after 8 years of trying to implement the old HIPAA, I
suspect that HIPAA Second Edition will evolve within HL7... hopefully,
out of the flurry of federally-inspired activity that began this spring
around the EHR initiative.
Hope springs eternal!.
With that, I believe it's time to call it a day! Have a great
weekend... and thanks for reading.
Christopher J. Feahr, O.D.
Optiserv Consulting (Vision Industry)
Office: (707) 579-4984
Cell: (707) 529-2268
http://Optiserv.com
http://VisionDataStandard.org