On Sat, 2003-08-09 at 11:17, Thomas Beale wrote: > 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.
Another test is asking those who are familiar with the actual, real-life vagaries, deficiencies and potential pratfalls of fielded EHR systems to pretend that they had some highly confidential medical condition or medical history, for which loss of privacy would be devastating, and then ask them to say truthfully if they would be prepared to entrust that medical record to the EHR system in question, using their real identity. Good candidates are senior IT people whose colleagues or employees are sysadmins or dbadmins of that EHR, system analysts, and security experts. Such a test needs to be carried out with an assurance of confidentiality so that participants feel free to fess up that things might not be a absolutely foolproof and watertight as everyone likes to think. I haven't devised a suitable punishment for those who say 'yes, I trust the system enough to have my highly confidential, potentially devastating medical history recorded in it under my identity'... > 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. Hear, hear! What a great summary of everything that is wrong with standards development. Can you publish that as a short essay on your Web site, or can I quote it with attribution elsewhere? Prototype, pilot, refactor, pilot again, start again, prototype, test, etc. No standard should be accepted unless its developers can admit that the first three versions turned out to be wrong when tested in real-life situations. > 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. Yup, and openEHR must be congratulated on this. My only criticism is that it has taken too long for openEHR to release working prototypes. I know these exist - but they need to be made public and readily useable for exploratory purposes, even if they are incomplete. Perfectionism is a curse. > > 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.... Indeed! I can think of a number of projects and organisations which appear to have nitromethane-burning supercharged V8-powered leaf-blowers... -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030810/c2db6a6e/attachment.asc>
