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
