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: Sources of information on HL7 EHR/OpenEHR
ok, we have real convergence here. OpenEHR works exactly like HL7 - define a reference model with all the needed semantics, and then refine things away in constraint models (and use the refinements as a basis for composition). So the principle is the same. We can generate [class models|schemas|wire formats] from constraint patterns. Doing so has benefits and costs. The same benefits and costs in either HL7 or OpenEHR. And one of the clear costs relates to persistence. I think we need to search for a better way, but that's not going to happen in the short term. But the OpenEHR HL7 reference models are quite different. In most parts, the HL7 reference model is more abstract (Which is way Act gets 22 attributes). So harmonising between the reference models is going to require actual change rather than adroitly altering perspectives, as with data types and the constraint model things. This will be hard, and painful. And it must involve compromise, so this is when we find out who really values collaboration. And we don't want to take away the real benefits that OpenEHR has in the process (same for HL7) Grahame
Antw: Sources of information on HL7 EHR/OpenEHR
Grahame, One of the theoretical difficulties of the debate that you are contributing so eloquently to is to separate methods proper to computing from methods defined by domain specificity. Object-oriented programming, modular design, abstract data types, etc. are fundamental principles whose existence does not follow from any particular domain features. They lead to better information modelling in terms of architecture, computational semantics and have been adopted as the best engineering methodology to create information processing systems. The abstractions that bridge the gap between computing and domain-driven modelling have to be able to represent in machine processable form the business objects we are dealing with. What you are doing in this case is less important than what you are doing it to. The marriage of the two strands does not deny their individuality but produces an offspring that blends their essential features in an organic way. openEHR contains RECORD in its name as the basic abstraction. The RECORD is a container structure that has well defined computational semantics - data entry is structured in the form of compositions that may be of different type (instruction, observation, etc.) because of differences in computing requirements - data representation, etc. Thus we have a model of a record (document) management system which at its highest level is generic. However, its type system is geared towards the faithful representation of information in the health care domain with the goal of producing a shared longitudinal patient record. HL7 as the name attests is based on the messaging paradigm. The MESSAGE has been historically the modelling abstraction that defines HL7. Thus, we have to ask ourselves, which root abstraction fits better the twin criteria of clear and purposeful computational semantics and faithful representation of domain specifics. You said: ok, we have real convergence here. OpenEHR works exactly like HL7 - define a reference model with all the needed semantics, and then refine things away in constraint models (and use the refinements as a basis for composition). So the principle is the same. (I have the feeling that you are thinking of HL 7 V4.0) Convergence is a really strong statement. I understand your motivation and your honest desire to overcome the gap between openEHR and HL7. However, one has to be equally honest in appraising the two approaches and their results. openEHR doesn't work exactly like HL7. A brief look at the history of the two would show that while openEHR has always been based on sound software engineering and knowledge modelling principles, HL7's effort to a reference model to its messaging structures is not necessarily a product of organic development, hence th gap between version 2 and version 3. openEHR does define a reference model with all the needed computational semantics but leaves domain-specific knowledge modelling to the second level of its methodology - archetype modelling. Implementation efforts have clearly shown openEHR's ability to produce clean clean computational models that enhance domain-specific semantic interoperability first and foremost throught the strict enforcement of the separation of concerns between information modelling and knowledge representation. The two sides click together at run-time in a very efficient and effective way. This is not refining things away in constraint models. The fundamental difference is how one deals with modelling or how one uses abstraction. Abstraction means to strip away the superficial or incidental aspects of a thing and to reveal its most important aspects, or essence, aka theory, hypotheses. Abstraction is important and can lead to deeper (beyond surface understanding ) of things. Abstraction can also go wrong. There are different ways to abstract. How do we test whether our abstractions (theories, hypotheses) are right or wrong? (to quote a good blog: http://billkerr2.blogspot.com/2006/08/ascending-from-abstract-to-concrete.html). The key to using abstraction in theoretical modelling is to understand how one can ascend from the abstract to the concrete. I don't think constraining and refining actually play such an important role in the design process. The same blog: Marx talked of ascending from the abstract to the concrete which on the surface can seem rather absurd. How can a concrete view of reality be superior to a more abstract view? We all know that science takes us beyond the surface appearance of things and proposes deeper explanations that are not immediately apparent. And anyone who has studied child development knows that initially children view the world in a concrete way and as they become able to think better they become capable of thinking more abstractly. So isn't abstract thinking more advanced than concrete thinking? The difficulty arises from confusing the Marxist idea of the concrete with the
Antw: Sources of information on HL7 EHR/OpenEHR
Graham, Isn 't is a matter of scope, as the thing we need to have agreement on first? Isn 't is a matter of requirements, as the thing we need to have agreement on second? Will the rest of the harmonisation process follow from that? I think that harmonising two things with substantial different scopes and requirements is impossible. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 19-sep-2006, at 4:30, Grahame Grieve wrote: This will be hard, and painful. And it must involve compromise, so this is when we find out who really values collaboration. And we don't want to take away the real benefits that OpenEHR has in the process (same for HL7) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060919/2204c91f/attachment.html
