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 -------------- 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/20030808/931d6469/attachment.asc>
