Hi All, An interesting conversation that, while deemed philosophical by some, is really very pragmatic.
A few weeks ago I said (on the openEHR Clinical list) I would write up more details about the 'why' (I did) and others should choose this approach to building clinical (or any other complex data) applications. This thread has prompted me to do so now. Christian's point of view is one that is widely held. There are problems with this view/approach on many points. Tom has expertly replied to some of them below. I want to speak to the issue of 'information in context'. An electronic health record is an information system about a person's physical, mental, emotional well being at any one point in time as that well being relates to the person's total 'known' physical and social environment. All proper decisions regarding any prognosis and/or plan on any level is based on information available at the time the decision is made. Therefore it is of primary importance that all pieces of KNOWN AND RECORDED information be able to be assembled as they relate to each other with regard to time. That is the present tense challenge and most EMR/EHR applications can meet that challenge. However, problems begin to arise as time passes. With the expected effective lifetime of an EHR easily exceeding 125 years we must anticipate that there will be huge changes in the recording and delivery of this information during the lifetime of a person's record. Without a crystal ball to give me that future knowledge I can look at recent history and reasonably expect similar changes. One issue that is seen in information systems in general is that schema's change. Information models grow/mutate to meet the demands of new knowledge and new expectations. The way this issue is handled most of the time is to either: a) migrate the existing data in one 'upgrade' process so it will all run under the new application version. b) maintain the ability to read the old data but migrate it to the new schema when it is accessed. These approaches work well for many applications. However, when it is important to be able to look back at a point in time and see exactly what a decision maker could see it should be obvious that you cannot make changes to not only the existing data but the environment it was recorded in (the context). This is an especially important issue in medic-legal situations as well as population health examination and probably many other areas health research. By building an application using a reference model that knows how to process version based archetypes you will have a framework that can change to meet new storage media and presentation demands and all those other technology changes we cannot yet see. However, the data can remain in the context in which it was originally recorded and be perable within the framework. There are other reasons that are particularly sensitive when using SQL databases. But, that is a long discussion and my time here is short. :-) I hope this provokes more discussion on this matter because outside of the people on these mailing lists there are few that agree at all with this approach and a small percentage of those in health informatics have even heard of it. It is important to me that I can present a reasoned case when I am in a situation that calls for me to discuss openEHR and the two-level modeling approach. A reasoned case almost always calls for practical applications where no other reasonable solution exists. Cheers, Tim On Fri, 2005-10-28 at 13:23 +0100, Thomas Beale wrote: > Christian Heller wrote: > > >Hi Thomas, > > > >taking the risk of being too philosophical, I reply to the list anyway. > > > > > > > you took the risk and you were;-) But that's ok, we like philosophy here... > > to briefly reply/paraphrase your remarks: you are suggesting that the > current split between the reference model in openEHR and archetypes is > nothing special, why not just have an object model of 1 or 2 classes > representing 'thing', and do everything in archetypes? This is certainly > theoretically possible - you would probably want a few more types, basic > data types and data structures are useful. We have stayed with the split > we have in openEHR because: > > * the world is not yet ready for having nothing at all in the software; > * we still need software to do basic computing tasks like creating > data, storing it, querying it etc. Most people's understanding of > that is based in an OO paradigm of classes and attributes. I agree > that in the future we might be able to move onto systems where > everything is done in archeytpe processing, but the health > informatics world is not yet ready for that. You only have to look > at models being built in CEN EN13606, HL7, IHE, ISO etc to see that. > * the part of the ontology that is in the reference model is that > part which people can agree is domain-invariant, i.e. always has > the same meaning (i.e. an Observation is an Observation is an > Observation, not matter what of). This means they can safely write > software and create data and it will work in current technology, > even with no archetypes. The archetypes layer is not invariant, > and is not meant to be. So, one way of understanding the split is > as between the layers ontology that everyone can agree on as being > constant, and on layers that are diverse and variable. > > So, in summary there is (and has to be) some pragmatism in what we are > doing... > > hope this helps. > > - thomas > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org -- Tim Cook, Consultant CHASE Health Informatics, Inc. GnuPG Key is available at http://www.chasehealthinformatics.com/Members/twcook -------------- 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/20051029/2a4fec29/attachment.asc>
