On Sun, 2003-12-28 at 13:55, Thomas Beale wrote: > yes, of course this is a more modern approach; it's the basis of more > serious HL7 architectures and products (like Oracle's Health Transaction > Base for example - a big centralised message switch).
Of course, putting everything through a single HL7 transformation hub may be more efficient than other approaches, but it also creates a large single point of failure - in particular, security failure. AFAIK, most HL7 transformation engines are designed to work with the HL7 segments "in the clear" - that is, not encrypted - which means that any compromise of the HL7 hub is fairly disastrous, and that the Hl7 hub administrators can, potentially, see everything that is being passed between all the applications and data repositories in the organisation. This fact doesn't seem to worry many people at all. But it worries me. Of course, the security risk posed by putting all informaion through a single hub is no worse than the risk posed by storing the EHR in a single repository which implements discretionary access control - by which I mean access control [1] which can be bypassed by an administrator or superuser. If the superuser account is compromised, the entire community which relies on that EHR is in deep excrement. But, you may say, compromise of the superuser account is impossible in a well-run system...just like the recent compromise of the FSF/GNU Savannah source code repository. [1] including access control implemented through encryption of individual records or the data storage medium which relies on a single key, rather than separate, record-level encryption keys. -- 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
signature.asc
Description: This is a digitally signed message part
