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. >
{Fraud?} {Disarmed} ADLv1.3 Archetypes for demographic and EHR
Hi I was just thinking to use some ADLv1.3 archetype files with java ADL parser. Could anybody give a pointer to ADLv1.3 archetypes? I could only find ADLv1.4 files here.http://my.openehr.org/wsvn/knowledge/ rgds minreddy - Get your email and more, right on the new Yahoo.com -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060917/53d58416/attachment.html>
Latest openEHR Architectural Overview
Hi Thomas I'm newbie to openEHR. My few cents to the Architecture document. Would it be possible to have visualization of runtime usecase scenarios which would include 1) adding new archetypes & templates to the system( parsing-storing to repository.) 2) how a template is used in the system, for example when an observation event happens. rgds minreddy Thomas Beale wrote: The openEHR Architectural Overview - the key technical document of openEHR - continues to benefit from community feedback. The latest version is at http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/overview.pdf If you have not downloaded a copy of this document for a few weeks, the new version is likely to be substantially better. Please keep the feedback coming... - thomas beale -- ___ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060917/944debe4/attachment.html>
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: Antw: Re: EHRcom/openEHR the new exciting paradigm
In een bericht met de datum 15-9-2006 23:15:45 West-Europa (zomertijd), schrijft randy.neall at veriquant.com: > > 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. > I am not a specialist on this, but I believe it is possible to have a quite simple DB schema based on HL7 v3. Difficult parts include the Entity parts (person, patient, organisation) because the entries in fields will change for some and not for other (e.g. changing addresses, phones etc. relationships between entities are handled via roles: that is not changing. participation from a role in activities are not changing. Of course there are different kinds of participation that change, but that is doable with coding then there are acts that have relationships with other acts, identifiers, moodcode and status codes, as are codes, times and where the act is an observation: there is a value. These parts of the RIM and D-MIMs have been stable for quite a while. Key of Act storage is to store the code for the act, the time, the author (via participation / role relationships), the mood (request, promise plan, carried out) and the status (activive, obsolete, competed). These things have not changed in principle. However, the D-MIMs derived from RIM have changed in those domains where development is ongoing. For some implementers it means for instance that the condition class cannot be used anymore. Instead we work with a problem list allowing activities to be associated on problem level and not on 'condition' level. Condition is changed to an observation. Part of this is because not all components of the HL7 v3 standard are ready now. Early implementers of work in progress thus will face changes that affect their developments. For the Netherlands national ICT project we include the industry in the work in progress and discuss this situation with them before starting and during development and balloting of standards. To prevent too many changes we have now the draft standard for trial use DSTU that allows a couple of years fixation of the standard, testing, finding out the problems, revising and then develop the final standard and ballot that. William Goossen -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060917/968058f4/attachment.html>
No religion, but discussion based on argumentation, dealing with the real issues
, and includes the particularities of the 13606, ensuring eventually, after careful and scientificall sound testing, that those who apply 13606 / OpenEHR in their record system can realise semantic interoperability with those that build their systems on HL7 v3 / Care Provision or similar approaches. Of course doing things directly is easier, and of course this will still cause a lot of troubles, and there comes the scientific debate on how to solve them. Now to my knowledge four systems based on HL7 v3 design are working in the practice arena, and to my knowledge three are in a far stage of development. Here I do not refer to the around fifty systems currently able to do the v3 messaging, but systems able to develop a record based on these principles. Another very harmonized approach is the work to develop care information models / clinical templates / archetypes / HL7 v3 templates/ OpenEHR templates / GPIC content / detailed clinical models. There is general agreement among CEN 13606 / Open EHR and HL7 v3 developers that the difficulty lies in the clinical detail, that vocabularies play a role here, that this can be sorted out and synthesised, that a more or less agnostic from technology model can be determined, and that the implementation into any technology is more difficult than implementing or transforming from one technology to another. A third area of harmonization is in the tooling. Where the agnostic modelling approach is far underway. One example is using the OpenEHR archetype editor to express the clinical content agnostically. Then I could make my care information models in such a way that they automatically transform to HL7 v3 message content. Of course the same clinical material would transform to an OpenEHR archetype, thus making the hard effort of sorting out the clinical stuff more cost effective and more worthwile. This can simply be achieve via adding / adjusting existing features of the archetype editor. The template editor could help us combining archetypes / R-MIM structures into larger components for EHR or message. E.g. from temperature, heartrate etc to vital signs panel, and combining this with other physical measures to a full physical exam / assessment. Then the next work underway is the transformations between technology a versus b versus c. I have not understood all details of the discussion between Grahame and Thomas, but I am sure that we are addressing real world problems with this work of making health information available to those with a need to know, and not some fanatisms belief. This might be not scientific, but at a certain point science tells me I have to stop being an expert because of limitations in knowledge and let the real experts in an area sort it out. For me the real techy stuff is the limit of doing science, and more the area of applying science that others develop. I see useful science going on on both sides. I fourth area of harmonisation is on the datatypes. I understood from a recent report of the ISO chair prof Kwak that this work is progressing. This means harmonization of CEN / HL7 / ISO work, allowing the science of medicine to express its data in different types necessary for practice and research, to store it and to exchange it independend of technology approach. Yes, there is work to be done, it is difficult, it is not finished, it is not a religion. In my opinion discussions on such harmonisation matters, with all pro's and con's, are useful and indeed a scientific debate. In my opinion shouting at everybody that "some standard 13XXX is the best" might relate to fanatism. I have never told anyone that there is one best standard, in contrary, I take a very eclectic approach, see for example: Goossen W (2006). Representing clinical information in EHR and message standards: analyzing, modelling, implementing. HINZ Primary Care and Beyond: Building the e-Bridge to Integrated Care. Eds: Christopher Peck & Jim Warren. Publisher: Health Informatics New Zealand (HINZ) & Health Informatics Society of Australia Ltd (HISA)/ISBN 0 9751013 7 4// ? The author(s) & HINZ All rights reserved. Thus, I would declare your mission to throw away HL7 as religious fanatism. :-) So again, thank you very much for pointing this out. William PS, on my behalf with defending my position here the debate on fanatism is closed, I will only reply to real harmonization work. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060917/f749d8e7/attachment.html>
