Henry Thanks for the 'dumb' contribution. I hope that you can see that openEHR has approached the problem in a way that will allow the sort of scenarion that you have painted as well as a more complex scenario with a distributed record - or even the big brother one record for each patient held centrally. The reason is that we cannot predict the size of future work units or the technology that will be around - only that the technology should not dictate the work practices - only support them.
Cheers, Sam > -----Original Message----- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Li, Henry > Sent: Tuesday, 11 June 2002 11:36 AM > To: 'openehr-technical at openehr.org' > Subject: FW: The concept of contribution > > > > > -----Original Message----- > From: Li, Henry > Sent: Tuesday, 11 June 2002 9:10 > To: 'Denis Nosworthy' > Subject: RE: The concept of contribution > > Hi > > I am not a real techno but I understand and deeply interested in the > discussion. I had this vision of a real good electronic health > record. It is > one own by the patient, carry by the patient, and presented to the health > care provider (whoever they are) by the patient (all over the world). The > Browser and XML or its improved version whatever it may be in the > future is > the way to go. > > This is the process > A patient visits a care provider and presents his e-card as a proof of > consent to treatment > > The health care provider loads up the health record into the browser and > download the info into whatever system he is using (this applies > to Hospital > as well), the health care provider can also choose to discuss the patient > with other health profession on line through the web. > > When the patient leave the care provider, it is the responsibility of the > care provider to upload whatever he has done to the patient back to the > e-card and the patient goes away. Any subsequent test results > etc, it is the > responsibility of the health care provider to contact the patient to have > the data put into the patient's e-card. (the patient can choose > not to do so > - but it is of course to the patients benefit to do so) > > The benefit of this is at any one time, the patient is the only > person that > has a complete health history of himself and he owns it. (Solve the > ownership and privacy issue) After all, currently, the health > care provider > will only know as much as what the patient choose to tell them anyway. > > New industry will start up to take care of the situation and provide all > sorts of support to the e-card holders. These services include how to > download, how to backup or even help retrieve data in emergency > etc. etc. - > god knows what will come up in the commercial world. Good or bad, no big > brothers. > > When the patient dies, he can choose to sell his e-card for research > purposes and has money to bury himself - no burden to next of kin. > > The reason I write these is that, I think I contribute as from a > dumb user's > point of view, may be it has some bearing on the design and the > structure of > the 'database' or 'rules' or whatever you may call it. The only > consideration will be where to put different types of health data in the > structure. It is upto the provider system to come up with the download and > upload method. > > Cheers > Henry Li > > > > -----Original Message----- > From: Denis Nosworthy > [mailto:Denis.Nosworthy at swsahs.nsw.gov.au] > <mailto:[mailto:Denis.Nosworthy at swsahs.nsw.gov.au]> > Sent: Tuesday, 11 June 2002 8:37 > To: 'Sam Heard'; openehr-technical at openehr.org > <mailto:openehr-technical at openehr.org> > Subject: RE: The concept of contribution > > << File: InterScan_Disclaimer.txt >> Sam, > > Well said. > > We have for many years been operating under the ideas of > 'interoperability' > and whilst tools such as HL-7 have been very successful in > getting us > through these times the issue of EHR interoperability will > be something else > yet again. Source system interoperability is one thing > however (mostly > constrained within a controlled environment) but receiving > systems such as > EHRs will have to be truly interoperable if they are to be > effective. > > The EHR is not a messaging system as some would have us > believe (in some > incantations it could be seen to be just that) but it must > be a system that > clinicians can rely on to be accurate and reflect 'real > life'. If it has to > rely heavily on 'real time' messaging then the vagaries of > our > telecommunications systems will have a significant impact on > that level of > acceptance > > -----Original Message----- > From: Sam Heard [mailto:sam.heard at flinders.edu.au] > <mailto:[mailto:sam.heard at flinders.edu.au]> > Sent: Tuesday, June 11, 2002 10:07 AM > To: openehr-technical at openehr.org > <mailto:openehr-technical at openehr.org> > Subject: RE: The concept of contribution > > > Dear All > > There is no doubht that the solution will have a degree of > complexity - just > look at HL7 v3 which is aimed at messaging. I believe that > the HL7 and CEN > EHR approaches will align - and will include the level 3 CDA > demands - > though it will take some time and must arise through > implementation > experience. The time for smoked filled rooms and EHR > standards is over for > us at openEHR and Ocean Infomatics. It is very helpful to > have lots of > ideas, but unless people are working on an implementation it > is almost > impossible to contribute in a major way. > > I have put the challenge to CEN to have some pilot > implementations of > Clinical Applications to GEHR (using our current trial > implementations) and > see what the implications are of our current approach. At > least 2 European > companies are interested. > > I also believe that the EHR demands an information model > designed > specifically for that purpose - the interoperability of > EHRs. The fantacy > that sharing information based on different information > models will be > straight forward is evolving - one only has to look at the > difficulty of > sharing a word document amongst different software - it is > often close. The > order of magnitude of complexity with health information is > far greater. > > So let us address the difficulties of information models, of > clinical models > in a two level approach and work to create an EHR that is > genuinely > interoperable. It will take resources - but to have it > working as a sharable > component will take 0.1% of about 3 countries health IT > development budget > and 10 good minds. > > I think it is really starting to happen! > > Cheers, Sam > ____________________________________________ > Dr Sam Heard > The Good Electronic Health Record > Ocean Informatics, openEHR > 105 Rapid Creek Rd > Rapid Creek NT 0810 > Ph: +61 417 838 808 > sam.heard at flinders.edu.au <mailto:sam.heard at > flinders.edu.au> > > www.gehr.org <http://www.gehr.org> > www.openEHR.org <http://www.openEHR.org> > __________________________________________ > > > > > > >Why the focus on HL7 only? CEN/TC251 has started work on > the EN 13606 > > >and > > is precisely what you want. HL7 version 3 and >CDA will be > to unstable > > for some time to come. HL7 doesn't adopt the GEHR (CEN) > two model > > approach. > > >Artifacts based on the present HL7 version 3 RIM will > prove to be > > unimplementable as a system or object. > > > > We can be very encouraged that you may get together with > HL7 on this. > > However you (or was it Gunnar Klein) did say in your > ?Berlin CEN > > meeting 2002 presentation (the presentation has > disappeared from the > > www.openehr.org <http://www.openehr.org> . site) that EN > 13606 had limited uptake because it > > was: > > > > a) incomplete or have offered only partial coverage of the > healthcare > > domain; > > b) unnecessarily complex; > > c) too generic, leaving the various implementations too > much > > variability in how the models are applied to a given > domain; > > d) flawed, with some classes and attributes not > implementable as > > published; > > e) requiring expensive re-engineering of systems; > > f) containing features not required by the > > purchasers of clinical systems. > > > > The time is evidently ripe for a synthesis. I agree about > the > > importance of > > narrative: > > You said: > > > > >It is a narrative for personal usage. > > >When information is to be shared the author will select > and rewrite > > >parts of his notes in order to meet a specific request by > an other > > >healthcare > > provider. > > >This is the way people work. This is the way healthcare > > providers know how > > > to work with using paper systems. > > > > Perhaps the record is a resource to make stories out of? > The original > > 'syntagm' is just the first, and even that was an > interpretation.The > > 'true' story is unknowable. > > > > > I can see that objective information (orders, test > results) can > > be shared > > by > > > all without real problems. But people (good healthcare) > will need > > subjective > > > narrative as recorded in their personal Medical Records. > > > > Free text remains indispensable, structured data is just > the debris > > left behind - it's a point of view... > > > > Regards > > > > Mike Mair > > > > > > > > > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org > <mailto:d.lloyd at openehr.org> > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > <mailto: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
