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 ----- Original Message ----- From: "Thomas Beale" <tho...@deepthought.com.au> To: <openehr-technical at openehr.org> Sent: Friday, August 08, 2003 6:17 PM Subject: Re: Distributed Records - An approach > Christopher Feahr wrote: > > >Thomas, > >You have described the situation succinctly with your statement: "My > >suspicion is that the gov has documented HIPAA as well as it can and is > >letting the healthcare community tell it what it said." > > > >I sense that our security experts are fairly happy with the HIPAA > >Security Rule... that it goes far enough, but does not stifle > >development or unreasonably increase costs... that it is essentially a > >codification of what most would consider "best practice". Same for > >HIPAA Privacy, really. We are hearing some consumer groups (the > >paranoid fringe) arguing for even more restrictive privacy policy than > >HIPAA... but I can tell you that my patients are more inclined to regard > >the whole thing as gross overkill and a waste of doctor's time. I would > >not quite agree with the latter because a good deal of the "security and > >privacy" that patients presently enjoy is afforded by their health > >information being scribbled into paper records and trapped in the > >doctor's back room. That DOES keep the information safe from prying > >eyes... of even the people who need to see it! > > > we should always keep in mind this point, as a benchmark of privacy > management of elecrnic patient information - from the patient's point of > view, if they see their information escaping more easily than it does > now (due to beig stuck in folders in the back room) then we are in trouble. > > >The rule that needs to be changed and is causing all the grief at the > >moment is the transaction rule. If our goal is to force lower > >operational cost with a regulation then, in my opinion, the regulation > >only need to FORCE representation of provider needs at the SDO level. > >Then common sense and the requirement that SDOs abide by a consensus > >process, should result in a standard that doctors can live with. > > > but the world does not work that way unfortunately - regulators can only > regulate actual things - delivered systems. > > >Representing the diverse requirements of all care domains at the SDO > >level, however, will require a substantially different labor/funding > >model for the SDO, and some heavy-duty automation/tools to handle the > >extensive vetting requirements with our dispersed (global) provider > >community. We also need more online collaboration tools and FEWER > >expensive, face-to-face SDO meetings. > > > I have argued before that the current paradigm of standards development > (of technical / information standards) is broken at the core anyway. > Here's why: > > - the SDOs in IT/technical areas are in the business of producing > technical specifications - what software engineers would call > "requirements", "analysis models", and other such things. > > - however, these things are not developed by any recognised software > engineering methodology, and often without any discipline whatsoever. > Instead they are developed by ad hoc argumentation in conference rooms, > by whoever happens to turn up, with whatever skills (often many skills, > but few relevant ones). Sometimes whoever shouts the loudest wins. > > - the current results of many technical standards definition efforts are > often arbitrary, contain bad modelling, and do not have proper > statements of the problem or rigourously developed technical artifacts. > > - the problem does not stop there. As people in software development > know, the best to test a design is o try to build it. Modern developers > understand the idea of "living documenation" - the docuemntation is > never finished, and is always under modification due to feedback from > implementation and actual use. That's why systems get rebuilt 2 or 3 > times before they are really good. This doesn't happen with standards. > They are published as static documents, and the available feedback > processes are so slow as to be nearly useless. Many standards processes > continue as talk/documentation fests for years before anyone seriously > tries to validate the models or designs. Professor David Ingram (UCL, > the inventor of the term "openEHR") has a mantra: "implementation, > implementation, implementation". He says this not because he is obsessed > with programming but because of the crucial value of feedback processes > in validating and improving specifications. > > - conclusion: any standards development process that is not a "live" > process with impleemntation and use and feedback loops, is not worthwhile. > > OpenEHR is far from perfect, but it is (trying to be) one thing: a > process, not a thing. The process is more akin to a software engineering > process, conducted in the open, rather than a staandards development > process. So in response to the above, some face to face meetings are > good, but they need to occur as design workshops, with competent > modellers and specifiers, and there needs to be implementation testing > of the results. > > >Using a govt. regulation to force a specific communication paradigm like > >X12-style EDI is simply the wrong place to apply the regulation. > > > I agree - this is like regulating that everyone must communicate with a > certain brand of mobile phone. > > > There > >is no "one size fits all" model for EDI. This has induced smaller plans > >and virtually all providers to simply push their EDI connection > >headaches onto the clearinghouse industry. I call it the "dueling > >leaf-blower problem". > > > that's a beautiful analogy! I'm sure I'm going to have to quote you on > this one day.... > > - thomas beale > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
