Hi Norbert, Excellent example! It is easy to imagine that a poll taken in the US would show that a majority of the public would believe this could not happen.
-Thomas Clark ----- Original Message ----- From: "norbert Lipszyc" <[email protected]> To: "Denis Nosworthy" <Denis.Nosworthy at swsahs.nsw.gov.au>; "'Tim Churches'" <tchur at optushome.com.au>; "Sam Heard" <sam.heard at bigpond.com> Cc: "Christopher Feahr" <chris at optiserv.com>; <lakewood at copper.net>; <openehr-technical at openehr.org> Sent: Friday, August 08, 2003 12:22 AM Subject: Re: Distributed Records - An approach > Identification, and authentication, has the been the subject of many > EUropean projects recently, mostly based on the use of smart cards. As one > example I can cite Smart-IS AM (an IST project of the European COmmission) > which has defined a "common smart-card module for authentication" and > another one for electronic signature. Therefore the technical ways of > solving this problem exist. The problem is social. In those countries where > a national identity card exist, there is acceptance for a unique > identification for health records also. In the others, such as the UK, there > is a lot of resistance and this will be solved only wen patients actually > see the advantage for their health to have a unique identification. Once > again, this will come only slowly. There was one tragic example of the need > for a positive unique authentication tool in France where in a public > hospital came two women with the same, identical demographics (names, birth > date and place town of residence). One came for a normal check on her > pregnancy, the other for abortion and ablation of ovaries due to a medical > condition, and the hospital made the mistake. This only points to the need, > not the aceptance of a positive authentication tool for people, but such > examples can emphasize to the public the reason for the need, mostly if the > identificaiton is different for health systems and other types of needs. > In short the technical tools are now available through the results of > several European projects. > Norbert Lipszyc > > ----- Message d'origine ----- > De : Denis Nosworthy <Denis.Nosworthy at swsahs.nsw.gov.au> > ? : 'Tim Churches' <tchur at optushome.com.au>; Sam Heard > <sam.heard at bigpond.com> > Cc : Christopher Feahr <chris at optiserv.com>; <lakewood at copper.net>; > <openehr-technical at openehr.org> > Envoy? : vendredi 8 ao?t 2003 01:05 > Objet : RE: Distributed Records - An approach > > > > > > I have been reading these threads with interest over the last few days and > I > > think the majority of the comments are extermely value and add to the > > debate. The focus is obviously on the structure and some of the mechanics > of > > the process but let me throw something else into the melting pot that is > an > > issue which does not seem to have received much airplay in the recent past > > anyway. > > > > It is the issue of identification and matching of clients. > > > > Far be it from me to raise the Australia Card issue again but the EHR > ain't > > (excuse my English) going to work unless the industry can crack this nut > in > > such a way that it is universally accepted by most Australians. > > > > Research that we have done over the past couple of years has indicated > > clearly that the majority of people we have surveyed (upwards of 3000 as > > part of another project) appear to have little concern about using an EHR > > however enacting the implementation of an "Australia Card' is another > issue > > altogether. > > > > I would be interested in the comments from those who have been close to > the > > action about what their own views are and what they perceive the client > view > > to be. > > > > Regards, > > > > Denis Nosworthy. > > CIO, South Western Sydney Area Health Service > > > > -----Original Message----- > > From: Tim Churches [mailto:tchur at optushome.com.au] > > Sent: Friday, 8 August 2003 06:49 > > To: Sam Heard > > Cc: Christopher Feahr; lakewood at copper.net; openehr-technical at openehr.org > > Subject: RE: Distributed Records - An approach > > > > > > On Fri, 2003-08-08 at 06:06, Sam Heard wrote: > > > Christopher > > > > > > It has been good to read this thread - but I have to wade in here. In > > > designing openEHR I have had a few principles in mind. > > > > > > 1. The technical solution should impose no constraints on social > > > behaviour. This means to me that if we want one EHR for each person > > > that is patient held or one repository for the entire country the > > > system should work. > > > > This is the only correct approach. Small, limited scope EHRs can always be > > amalgamated later to create larger scope EHRs. However, grand, > > all-encompassing EHR schemes are, at this stage, in most countries, bound > to > > flounder on both socio-political and technical rocks. We should be worry > > about crawling across the room competently first, but forearmed with the > > knowledge that in a decade or so we will be running marathons (and hence > > should start out with an approach which can go the distance > > apologies for the mixed metaphors there). > > > > > > > > 2. Linking records is non-existant at the moment and we can move > > > incrementally towards an environment where we know where health > > > information about an individual resides. Once you start to send EHR > > > data from one site to another in openEHR then the links will build > > > automatically. Remember, sometimes the patient will not want their > > > information to flow! and while the technical view of security checks > > > seems omnipotent, partitioning will always be safer. > > > > Every Monday morning, anyone working in this field should re-read the BMA > > criteria for privacy of patient data, as drawn up by Ross Anderson in the > > mid 1990s - see http //www.cl.cam.ac.uk/users/rja14/policy11/policy11.html > > > > A few moments reflection on these principles reveals that there are many > > very complex problems for which definitive or even satisfactory solutions > > don't yet exist - for example, if a patient consents to access to their > EHR > > by clinician A, under what circumstance can that consent be extended to > > other clinicians, and is the extension of consent transitive, and/or > > commutative? This extends to knowledge that an EHR record for a patient > > exists (or even that the patient exists), not just to the contents of that > > EHR. Very tricky stuff indeed, which is usually swept under the carpet in > an > > intra-institutional setting, and increasingly in vertically integrated > > healthcare organisations - but organisation won't be able to do that > > forever, and these issues certainly can't be ignored for community-wide > > EHRs. It will take many, many years, and many many (probably failed) > > attempts before well-accepted solutions to these problems are available. > In > > the meantime, start small... > > > > > > > > 3. openEHR offers a one to one transform for all information in EHRs. > > > Our idea is that openEHR servers will retain the comprehensive > > > information that comes from legacy or specific systems. Other systems > > > will develop their read and write interfaces with openEHR and that > > > will be all they need (at some future date) to operate and > > > interoperate with EHR systems. Could be fantacy but it looks sweet - > > > we are moving to a real-time trial of this approach in Australia. > > > > Which means that release of a production-quality open source openEHR > kernel > > is approximately how many years away, more or less? > > > > Tim C > > > > > > > > Cheers, Sam > > > > > > > -----Original Message----- > > > > From: owner-openehr-technical at openehr.org > > > > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Christopher > > > > Feahr > > > > Sent: Wednesday, 6 August 2003 12:59 AM > > > > To: lakewood at copper.net; openehr-technical at openehr.org > > > > Subject: Re: Distributed Records - An approach > > > > > > > > > > > > Thomas, > > > > This sounds workable to me. If I am understanding you correctly, we > > > > need one (and only one??) registry in which anyone, anywhere (who is > > > > authorized, of course) could look up a patient and determine which > > > > "region" had master control at the moment over his record. If I'm a > > > > provider living in the region where the records are primarily > > > > managed, then when my system attempted to look up, say, the date of > > > > his last Tetanus vaccination, it would find it immediately. If I > > > > was a provider visited while the patient was traveling outside his > > > > "home" region, then the same local query about his tetanus shot > > > > would tell me: "hold on a minute, while we search all known > > > > registries to see where this guy's home-region is... where his most > > > > current records will be located". ... and then my region does a > > > > full record update from the current home region? or just try to > > > > display his tetanus vaccination history? > > > > > > > > One of the problems alluded to is that different regions might be > > > > using very different EHR structures. Thus a simple "record refresh" > > > > in region B from the information stored in Region A is not so > > > > simple. It would involve mappings at least, and possibly even data > > > > transformation. The inability to assume an overarching authority > > > > seems to be the Achilles heel. After a dozen record "movements" > > > > from one region to the next, many little mapping and transformation > > > > errors may have accumulated to thoroughly hose up the medical > > > > information in the patient's "master" record. > > > > > > > > One way around the central record managing authority would be to > > > > have VERY FEW regions... each with a well organized regional > > > > authority... who come together under a global organization and work > > > > out a very tight choreography for these refresh/hand-off operations. > > > > But this sounds harder and no more likely to be created as one > > > > single authority such as the UN imposing the requirements on all > > > > regions. > > > > > > > > I believe that the most critical point for global standardization > > > > and what we must aim for (first) is the information in the record. > > > > When the world has settled into that (something that will ALSO > > > > require a central authority, but just for standardizing what the > > > > information elements mean, not for choreographing complex > > > > record-merge operations), people will gradually come around to the > > > > idea of moving to the next level of system interoperability, with > > > > standard record structures. > > > > > > > > With only the information standardized globally, two large and > > > > cooperative regions (say, US and Australia) could still choose to > > > > create a US-Aus. information authority and orchestrate a high level > > > > of interoperability for patients and providers floating anywhere > > > > within our two countries. If the "functional regions" initially > > > > were more along the sizes of counties and states, then we'd have a > > > > lot more hassle and negotiating. So I would suggest the world start > > > > with the largest sized regions that could be reasonably managed with > > > > the same EHR structure. > > > > > > > > The critical issue for all regional participants would be a strong, > > > > competent regional authority... that operated in conformance to a > > > > set of well defined "regional authority rules"... maintained by the > > > > UN?? > > > > > > > > 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: <lakewood at copper.net> > > > > To: <openehr-technical at openehr.org> > > > > Sent: Tuesday, August 05, 2003 12:11 AM > > > > Subject: Distributed Records - An approach > > > > > > > > > > > > > Hi All, > > > > > > > > > > With a background in fault tolerant computing I have a built-in > > > > penchant for > > > > > distributed files that are exact/backup copies of a master. Works > > > > wonders > > > > > for > > > > > financial transactions. > > > > > > > > > > I don't believe that this model fits EHRs especially since one can > > > > conceive > > > > > of > > > > > parallel, e.g., close proximity in time, operations directed at > > > > > modifications originating at geographically distant > > > > > locations.These operations, even > > > > they > > > > > occur > > > > > across town (Clinic and distant Lab) create problems for record > > > > management. > > > > > > > > > > Tying record management to physical location is not a solution. > > > > > Remote medicine complicates this immediately. However, a constant > > > > > occurs immediately, presuming that we do not have to deal with > > > > > human clones (put a > > > > <dash-number> > > > > > in the ID). The Patient ID is it. Traditional approaches would > > > > > require > > > > that > > > > > in all > > > > > the world there is only one unique person being considered. > > > > (hopefully). > > > > > > > > > > Hence each region could contain entries on residents, transients, > > > > visitors. > > > > > tourists, etc. that somehow make contact with healthcare > > > > > facilities/Practitioners in the region. > > > > > > > > > > Registering the IDs and updating the regional databases requires > > > > > that > > > > only > > > > > those > > > > > regional Patients be administered. > > > > > > > > > > National and international databases can be established that will > > > > receive > > > > > and store > > > > > regional registrations of Patient IDs, allowing one to scan these > > > > databases > > > > > to > > > > > determine who holds regional records on individual Patients. One > > > > > can > > > > then > > > > > retrieve all the records or part of them. This substantially > > > > > reduces > > > > the > > > > > need for > > > > > storage and bandwidth to manage records on a global scale. > > > > > > > > > > I presume that there is no need to have matching records for > > > > individual > > > > > Patients > > > > > in all regions this Patient has been in an made contact with the > > > > healthcare > > > > > industry. If I take a cruise on the Rhine and require medical > > > > attention it > > > > > makes no > > > > > sense to burden whatever region manages that healthcare system > > > > > with > > > > anything > > > > > more than they had a tourist with a weak stomach. > > > > > > > > > > It would be nice to have a distributed registry that would show > > > > > where > > > > I had > > > > > to > > > > > stop off and get some help. At least the Public Health personnel > > > > > would appreciate it. > > > > > > > > > > The important thing to me is to be able to access all the known > > > > records and > > > > > bundle them in a way that is appropriate for the healthcare > > > > > personnel handling my latest complaints. > > > > > > > > > > BTW: The Fault Tolerant/Highly Available Systems can make sure > > > > > that > > > > the > > > > > information requested is available but the applications have to > > > > structure > > > > > it. > > > > > > > > > > -Thomas Clark > > > > > > > > > > > > > > > - > > > > > 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 > > > > > > - > > > If you have any questions about using this list, > > > please send a message to d.lloyd at openehr.org > > -- > > > > 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 > > > > > > > > This message is intended for the addressee named and may contain > confidential information. If you are not the intended recipient, please > delete it and notify the sender. Views expressed in this message are those > of the individual sender, and are not necessarily the views of South Western > Sydney Area Health Service. > > - > > 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
