On Wed, 2004-03-10 at 21:31, b.cohen wrote: > I produced a formal definition of most of Anderson's Security 'Principles' in > 1996 (see http://www.soi.city.ac.uk/~bernie/hsp.pdf)
Nice paper! Haven't read it in detail but on a quick scan I see the value in the formalisation. > and circulated it within > TC251 and ASTMS 31.1 in an attempt to promote a more formal approach to the > definition of EHR standards in general, and their security in particular. > This approach was met with almost universal hostility from both supply and > demand communities. > The problem is not only that formalisation is intellectually difficult but > that > it exposes logical inconsistenciies in the composition of what practitioners > and users believe to be in their best interests (and promote as 'common > sense'). Yup, but these tensions need to be worked out before you invest in building vastly expensive community-wide EHRs - because they will surely come to light once the thing is in operation, and by then they will be even more expensive, or impossible, to fix. > The exposure of such inconsistencies, and their repair by altering models on > both the supply and demand sides, is the essence of strategic development. > Unfortunately, it is also the bane of standardisation. Apart from altering models, it is also possible to press new technologies into service. For example (wearing my epidemiologist hat now), many of the new "privacy-preserving" data mining techniques, based on secure multi-party computation, can now be used to solve many of the researcher vs individual privacy issues. The "emergency access" problem is tricky, but reasonable compromise schemes can be worked out - although they may be expensive. I think that is teh bottom line: no-one likes the fact that to do EHRs properly costs a lot more than maintaining all the redundant copies of the partial paper records which we currently maintain. Do the benefits outweigh the costs, and the benefits can't really be assessed until someone has built and operated a comprehensive community-wide EHR for half a decade or more. Tim C > > Quoting Tim Churches <tchur at optushome.com.au>: > > > On Tue, 2004-03-09 at 23:20, Thompson, Ken wrote: > > > 2) A mechanism on the patient record itself that displays a list of all > > > users that have accessed the record (with date and time). This will > > probably > > > be made available to the patient at some point, so they will actually > > > provide a critical part of the checks and balances in the system. > > > > This is similar to the mechanisms envisaged under the "Consent and > > notification" secion of the now-famous BMA Security Policy, developed by > > Ross Anderson - see > > http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html > > > > This is still the gold standard for EHR security policies, IMHO, yet > > most people I have met who are involved in EHR work and who know of it > > (curiously many seem ignorant of it) tend to dismiss it, not because the > > policies are unsound (although they do need minor tweaking here and > > there), but because implementing them is very difficult in practice - > > particularly the multilateral as opposed to multilevel access control > > policy. In fact you need both, but of the two, the former is more > > important. In other words, role-based access control, where the "roles" > > are specific to each patient, as well as to each health professional. > > > > > > -- > > > > 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 > > > > > > -- 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/20040310/d83ca847/attachment.asc>
