Antw: Re: Antw: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060926/15a2107b/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm
and Excel as you are now. What we need is equivalent openEHR archetype for each of your Care Statement RMIMs and in your mapping spreadsheet a couple of columns for the openEHR archetype mappings. Once we get the process right we can then develop the tools to support it. BTW, a member of my development team (who was a obstetrician) is going through the process of developing a pregnancy clinical scenario (mega storyboard) and mapping the data element and sample data into archetypes. I wonder of you would be interested in working with her or at least sharing your experiences and current process? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: mailto:heath.frankel at oceaninformatics.biz heath.frankel at oceaninformatics.biz _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: Tuesday, 19 September 2006 7:01 AM To: openehr-technical at openehr.org Subject: Antw: Re: Antw: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm In een bericht met de datum 18-9-2006 10:45:04 West-Europa (zomertijd), schrijft Thomas.Beale at OceanInformatics.biz: There are guideline and workflow languages (not provided by HL7 or openEHR), and the beginnings of models for choreography coming from WfMC and other places. I have looked into the WfMC materials, and the basic process flow descriptions are currently met with the HL7 v3 Care Plan. (This is not a point if HL7 can do, it is the point that it is possible to define the clinical process using a standard, I think it is transferable to OpenEHR archetype as well). The key here is the use of the following mood codes: definition will tell you wat according to best practice or evidence base should be done for a patient with problem x. (including monitoring of observations, tests, meds etc). The OpenEHR template specification that links archetypes could perhaps do similar things. intent mood helps the clinician to carry over from guideline into the care plan what is necessary for individual patient P. Thus the set of data required can be determined, and it can be justified why items are not carried from guideline to plan. (E.g. you do not female things for a male patient). Then if some professional wants to order a observation this can be done with request. e.g. the doctor askes the nurse to measure the blood pressure 4 times a day. In the Goal mood, the expected value can be set, e.g. the expected value of BP in a week should best be 130/90. the observatoin is carried out say 7 days 4 times a day leading to 7 x 4 = 28 observations in event mood. The statement collecter allows to trend this. The comparison of goal versus the event(s) trends, or the last value of day 7 allows to determine if the goal is met (conclusion being then the 29th observation). The derivation method allows to specify also workflow rules like: do BP measurements until 4 x 130/90 or similar as a criterion for the do X until Y workflow standard. I am not telling this is best handled in HL7 v3, I just want to say that a] it is possible to express clinical meaningful workflows, that at EHR level are pretty handy for a nurse to pop up on the worklist every 6 hours, and that it is possible to exchange the semantics of such a workflow / careplan via a message. Yes, this is interesting stuff and needs a lot of work. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060919/6fb3e1b3/attachment.html
Antw: Re: EHRcom/openEHR the new exciting paradigm
As an unqualified lurker in these groups I must say I was v. impressed by the breadth and depth of knowledge of HL7 that Thomas Beale has shown in these recent discussions - it gives me even more confidence in the principled basis behind openEHR and the openess of the openEHR people in their responses. my2cents \Gavin Brelstaff CRS4 Italy William E Hammond wrote: Gerard, I am amazed at the comments to your collegue. We are making great strides in bringing ISO/CEN/HL7 together with the potential of taking a step beyond even harmonization. I am in favor of pro and con discussion. As I read your earlier mail, I interpret those remarks as saying we don't need HL and don't even look at HL7.
Antw: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm
In een bericht met de datum 15-9-2006 22:21:23 West-Europa (zomertijd), schrijft gfrer at luna.nl: snip snip: I agree. There is only one patient, with one problem that needs our unified attention and devotion. So we have to co-operate. But we have to continue to discuss and provide arguments and listen to the arguments given. Instead of attacking persons, as I have been able to observe several times it to happen in the Netherlands. Lets start the real debate. Patients and healthcare providers need real solutions that empower them. Gerard I agree with several comments on HL7 v3, there are solutions for that underway. I agree that CEN 13606 / Open EHR and HL7 v3 have their advantages and disadvantages. I agree that we can work together I agree that there is a lot to be done I agree that both approaches have led to implementations and also to the determination of problems in the technological approach. I disagree that we should discuss this from a view point of superiority of one approach against the other. That is the WW 1 approach. That WW1 'for or against' approach will not lead to working solutions. My comments are based on believing that your points 1-6 are sensible to discuss and find solutions. Your comment 7 is not useful and I would suggest you to refrain from the pro - con discussion. For the one patient with always more problems (there is no situation in health care where a patient has only one problem, he might have one disease, but that will always have more than one interelated problems) that need our dispersed attention to tackle this in a holistic way. So the 'standard' approach is: one patient with one or more diseases and none to many associated problems / complaints and none to many associated nursing diagnoses / allied health problems and one to many activities for the disease (s) and one to many activities for the associated problems (the minimum, so always one has to be there is to monitor the onset of a potential problem) and one to many activities for the associated nursing diagnoses / allied health problems. Definitely this is is with respect to workflow a difficult non-linear process of care delivery and of changes of the disease(s) and the different problem situations. Thus we need to be able to have a system that can track what these changes are, and what the status of this set of mixed activities is. We must also be able to exchange this in the multitude of systems available in health care that will last for several decades. I am pretty sure that I can deal with these complex situations in HL7 v3 speak. I have not seen examples of these complex care situations in 13606 speak since that is missing examples from health care with this respect. Perhaps we need to work more from the clincial perspective and determine the requirements and from there to the technical bits. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060917/1224b874/attachment.html
Antw: Re: EHRcom/openEHR the new exciting paradigm
Dear William, One very important point I forgot to make: You wrote: Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future. What you write is that any discussion pro or contra a point of view will lead to a kind of war and prevents good results in the future. This line of reasoning is strange for a person active in academic worlds with a PhD thesis in his CV. A discourse pro and contra a point of view is the essence of science because it leads to better understanding of our complex world. This line of reasoning of yours makes me feel uneasy because this way of argumentation is one seen in religious fanatics that don't want any real discussion. With regards, Gerard Freriks -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-sep-2006, at 19:08, Williamtfgoossen at cs.com wrote: Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060916/16b56c63/attachment.html
Antw: Re: EHRcom/openEHR the new exciting paradigm
Gerard, I am amazed at the comments to your collegue. We are making great strides in bringing ISO/CEN/HL7 together with the potential of taking a step beyond even harmonization. I am in favor of pro and con discussion. As I read your earlier mail, I interpret those remarks as saying we don't need HL and don't even look at HL7. I don't think such remarks encourage a position of cooperation. I would sugget to Randy that he look at both HL7 and openEHR. Both have components in their favor and both have cons. It is my believe that working together gets us further along the road. I don;'t fully know what the referral is to an ever-changing schema at the DB storage level. CCD is becoming the recommended standard for the exchange of data in HL7. On the other hand, I think the work with archetypes brings a lot into the equation. Competition is good at some times and destructive at others. Incrediably stupid doesn't sound like a scientific argument. I am sorry for these remarks, but I needed to express them. Ed Hammond Randolph Neall randy.neall at veriquant.com Sent by: openehr-technical-bounces at openehr.org 09/15/2006 05:08 PM Please respond to For openEHR technical discussions To: For openEHR technical discussions openehr-technical at openehr.org cc: Subject:Re: Antw: Re: EHRcom/openEHR the new exciting paradigm I'm a .Net developer in the U.S. researching development of EHR. I've been absolutely fascinated by the recent debate between advocates of HL7 and openEHR. For me it was hugely informative and I'm glad it all happened. You don't learn this stuff just be reading the papers from each community. Since I'm not sufficiently acquainted with all the details of either system I could not follow each nuance of the argument. But among the things I'm taking away from this is that HL7 involves a complex and ever-changing schema at the DB storage level, something that worries me. I did not hear a rebuttal of this point from the HL7 side. Randy Neall Veriquant, LLC tel 828-685-1302 fax 828-685-1957 randy.neall at veriquant.com - Original Message - From: Gerard Freriks To: For openEHR technical discussions Cc: grahame at jivamedical.com Sent: Friday, September 15, 2006 16:07 Subject: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm Dear William, Either the brave Dutch are stupid or very clever to become almost the only nations on this earth to vote negative on: the CEN/tc251 EN13606 EHRcom and HISA standards. I know one thing for certain. Based on the openEHR specification in TNO project we have one working implementation from Sweden using Java and one from Australia using .Net. And besides openEHR and CEN/tc251 are based on several working implementations produced in many European projects. Not only the theoretic foundation is in order, the implementations are there, and they work as claimed. It can be proved this solutions are scalable. I know that there are parties that started to implement HL7v3 messages on a large scale and encountered scalability problems. There parties are changing there point of view and are moving towards CEN/tc251 EHR related standards. To read recently in a HL7 e-mail list a discussion dealing with the definitions used in HL7 with respect to several of the founding classes of the RIM (Entity and Act) and the confusion in the documentation is a tell tale example of only one of the serious problems in the HL7 community. And all this after 10 years of work and the production of tons of documentation that can not be printed. You can reverse any statement I make. You can decide not to believe any statement I make, as you and several of my country fellow man did when we were discussing EN13606 EHRcom, lets see how history will prove who is right and who is wrong. So we stop this debate and see how things evolve in time. In the end what matters is, not only that the healthcare sector is able to express what they want, but can it Plug-and-Play be implemented without reprogramming. And then I'm confident that openEHR and CEN/tc251 EHRcom plus HISA will provide just this, because it was in our requirements, also, from the start. I agree. There is only one patient, with one problem that needs our unified attention and devotion. So we have to co-operate. But we have to continue to discuss and provide arguments and listen to the arguments given. Instead of attacking persons, as I have been able to observe several times it to happen in the Netherlands. Lets start the real debate. Patients and healthcare providers need real solutions that empower them. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-sep-2006, at 19:08, Williamtfgoossen at cs.com wrote: This is reversable: When the world starts to experience the multitude of difficuties with the OpenEHR and CEN
Antw: Re: EHRcom/openEHR the new exciting paradigm
In een bericht met de datum 15-9-2006 18:56:19 West-Europa (zomertijd), schrijft gfrer at luna.nl: -7- Then the question arises: When the world starts to experience the multitude of difficuties with the HL7v3 RIM and message development method what will we do? Will we start to patch up something that has intrinsic problems? (Do you remember the recent discussion on a HL7 e-mail list. My conclusion was that they don't know the definitions of the major classes of the RIM. Luckily HL7v3 is not deployed that widely, so there are not much legacy systems to reckon with?) Or will we start from a more sound starting point. One that will become an European standard and is on its way to become an ISO standard as well? This is reversable: When the world starts to experience the multitude of difficuties with the OpenEHR and CEN 13606 and archetype development method what will we do? Will we start to patch up something that has intrinsic problems? Do you remember the recent discussions on the OpenEHR list. My conclusion was that they don't know the definitions of the major classes of the RIM and other technicalities. Luckily OpenEHR / 13606 is not deployed that widely, so there are not much legacy systems to reckon with? Or will we start from a more sound starting point. One that is an International standard and is on its way to become an ISO standard as well? Of course this reversion is just to point to the fact that we are apparently back in our corners and have this dispute that is nonsence and not contributing. I am the last to tell that HL7 v3 is perfect, but will be one of the firsts to tell it is working. I am the last to believe OpenEHR / 13606 is perfect, and wait till I see it work in real practice. In the meantime, we have harmonized and differences (few) and commonalties (biljons) have been determined. In the meantime, we will start working with existing tools, set requirements and improve the tools. I do not care where the tools come from, I care what they can do for the very difficult work of entering, storing and exchanging information about patients and care in a intelligent, semantic interoperable way. I do like HL7 v3 D-MIMs because I see several good working EHR systems based on this. To me, beside philosophical problems (fundamental to limits in human thinking), and technical approaches, it really does not make a difference: make the clinical materials available electronically and make clinicians not have to worry about the technology and transformations behind. Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/f0f29275/attachment.html
Antw: Re: EHRcom/openEHR the new exciting paradigm
I'm a .Net developer in the U.S. researching development of EHR. I've been absolutely fascinated by the recent debate between advocates of HL7 and openEHR. For me it was hugely informative and I'm glad it all happened. You don't learn this stuff just be reading the papers from each community. Since I'm not sufficiently acquainted with all the details of either system I could not follow each nuance of the argument. But among the things I'm taking away from this is that HL7 involves a complex and ever-changing schema at the DB storage level, something that worries me. I did not hear a rebuttal of this point from the HL7 side. Randy Neall Veriquant, LLC tel 828-685-1302 fax 828-685-1957 randy.neall at veriquant.com - Original Message - From: Gerard Freriks To: For openEHR technical discussions Cc: grahame at jivamedical.com Sent: Friday, September 15, 2006 16:07 Subject: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm Dear William, Either the brave Dutch are stupid or very clever to become almost the only nations on this earth to vote negative on: the CEN/tc251 EN13606 EHRcom and HISA standards. I know one thing for certain. Based on the openEHR specification in TNO project we have one working implementation from Sweden using Java and one from Australia using .Net. And besides openEHR and CEN/tc251 are based on several working implementations produced in many European projects. Not only the theoretic foundation is in order, the implementations are there, and they work as claimed. It can be proved this solutions are scalable. I know that there are parties that started to implement HL7v3 messages on a large scale and encountered scalability problems. There parties are changing there point of view and are moving towards CEN/tc251 EHR related standards. To read recently in a HL7 e-mail list a discussion dealing with the definitions used in HL7 with respect to several of the founding classes of the RIM (Entity and Act) and the confusion in the documentation is a tell tale example of only one of the serious problems in the HL7 community. And all this after 10 years of work and the production of tons of documentation that can not be printed. You can reverse any statement I make. You can decide not to believe any statement I make, as you and several of my country fellow man did when we were discussing EN13606 EHRcom, lets see how history will prove who is right and who is wrong. So we stop this debate and see how things evolve in time. In the end what matters is, not only that the healthcare sector is able to express what they want, but can it Plug-and-Play be implemented without reprogramming. And then I'm confident that openEHR and CEN/tc251 EHRcom plus HISA will provide just this, because it was in our requirements, also, from the start. I agree. There is only one patient, with one problem that needs our unified attention and devotion. So we have to co-operate. But we have to continue to discuss and provide arguments and listen to the arguments given. Instead of attacking persons, as I have been able to observe several times it to happen in the Netherlands. Lets start the real debate. Patients and healthcare providers need real solutions that empower them. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-sep-2006, at 19:08, Williamtfgoossen at cs.com wrote: This is reversable: When the world starts to experience the multitude of difficuties with the OpenEHR and CEN 13606 and archetype development method what will we do? Will we start to patch up something that has intrinsic problems? Do you remember the recent discussions on the OpenEHR list. My conclusion was that they don't know the definitions of the major classes of the RIM and other technicalities. Luckily OpenEHR / 13606 is not deployed that widely, so there are not much legacy systems to reckon with? Or will we start from a more sound starting point. One that is an International standard and is on its way to become an ISO standard as well? Of course this reversion is just to point to the fact that we are apparently back in our corners and have this dispute that is nonsence and not contributing. I am the last to tell that HL7 v3 is perfect, but will be one of the firsts to tell it is working. I am the last to believe OpenEHR / 13606 is perfect, and wait till I see it work in real practice. In the meantime, we have harmonized and differences (few) and commonalties (biljons) have been determined. In the meantime, we will start working with existing tools, set requirements and improve the tools. I do not care where the tools come from, I care what they can do for the very difficult work
