On Wed, 24 Dec 2003, Thomas Beale wrote: ... > > 1) Are archetypes versioned? > > How does OpenEHR support old data when achetype is changed? > > > yes, they are versioned. > There is a formal definition of the various flavours of changes to > archetypes you can make - here is a rough version:
> - versions - fix an error in an existing archetype; this implies the > data created via a previous versions is slightly wrong, and a new > version always have to suply a conversion algorithm to deal with it. This is how you manage addition, changes, and deletions of attributes, correct? Can "OpenEHR Templates", for example, continue to use the older version? Meaning, can multiple archetype versions co-exist at a given point in time? > - specialisations - further specialise an existing archetype; only > narrower constraints are allowed, guaranteeing that the parent archetype > can deal with data created by the new specialised version Do you mean the addition of an attribute? With "specialization", the parent archetype is retained, correct? > - revisions - make changes which do not have any effect on existing > data, e.g. add a new language translation of all the terms ok, but adding an attribute falls under "specialization", not revision? ... > the workflow to do with a PAP or vaccication recall is qualitatively > different from the workflow to do with discharge referral and other > events where the patient gets sent around the health system to other > providers (and usually back as well). How so? I think they can be all be modeled using the same workflows metamodel. ... > When I say that archetypes are globally defined, I mean that they are a > priori designed as globally, or widely (maybe nationally, or across an > entire specialty or disease category) usable, Same as OIO forms. > and carry a conceptual definition that can be widely agreed to, Same as OIO forms. > even though the concrete screen and data realisations in particular > systems will be quite different. Same as OIO forms. > >>>What if you use different archetypes across these exams to represent > >>>blood pressure? ... > If two parties want to use different archetypes for "Systemic arterial > blood pressure measurement" but still share data, then there will > clearly be some conversion /translation to do on the data - that can't > be avoided. Right, that's what I tried to convey. ... > >A few _classic semantic representation problems_ come to mind: > >1) What if I add "4th sound" and another end-user independently also adds > >"4th sound" - and we describe "4th sound" differently? > > > if they both map it to a relevant UMLS, snomed or Loinc term - they will > more or less be obliged to choose the same term from these > terminologies. Does OpenEHR require the use of terms the come from one of those terminologies? > >2) What if I add "4th sound" and another end-user independently adds > >"extra sound" to describe the same observation? > > > It depends on whether you are talking about independent modifiers in > different countries, or two clinicians in the same provider > organisation. The key thing to remember is that the lifecycle of an > archetype is not simply - modify and start using in the production > system - there has to be plannnig, review, approval before it can be > injected into the system; Why not shorten the cycle and just inject it into the system. Then, later build translators if they are needed? ... > >*With flexibility to create new terms (=OpenEHR archetypes/OIO forms) > >comes need for translation between terms.* Do you disagree? > > > > > do you mean terms as in Snomed terms or the like? Kind of, I mean the creation of OpenEHR archetypes or OIO forms is basically creation of terms. A form-to-form translator is equivalent to defining relationships between terms. ... > >>not so they can then go and invent unrelated ones to do the same job. > > > >Perhaps this is a fundamental difference between OpenEHR and OIO: > > > >I am of the opinion that end-users *can* and *must be allowed to* go and > >invent whatever forms/archetypes they wish even if you or any so-called > >"experts" believe we already have forms that do exactly the "same job". > > > >This "freedom of expression" is a core aspect of OIO. > > > well, I'd say it is a core aspect of a pluralist society. OpenEHR works > within such a framework, its just that it is trying to find ways to make > collaboration easier and minimse replication of work. How does OpenEHR make collaboration easier and minimize replication of work? > OpenEHR is certainly not going to stop anyone from using all the > software and creating an entire mountain of unrelated incompatible > archetypes to use in their institution. Good luck to them I say;-). I think we can and should do more than wishing them good luck! This is because that's how people work - we know that, there is no doubt humans will build a tower of Babel yet again. :-) We need to fit the tool to the people and not the other way around. Thus, I think *supporting interchange* of data between different OpenEHR archetypes and OIO forms must be a key feature of the software system. In other words, facilitating collaboration and minimize duplication of work via easy to build and use _translators_, rather than expecting people will refrain from building different archetypes and forms to represent related or identical concepts (= Tower of Babel). ... > >Data items occur on the same form by design and carry a great deal of > >semantic significance. Ask anyone who ever designed forms and they > >will agree. > actually I do agree, more or less - depends on the form. I don't think it depends on the form at all. All forms contain useful contextual information. :-) ... > archetypes) - but - they still represent an attempt to put a certain > selection of information on the screen or report - and the design > mentality here has to be influenced by GUI design factors, e.g. commonly > accessed things are a minimum number of keystrokes away, visual real > estate is used in a way that the square area/colour etc of a widget > corresponds to its importance to the user, etc etc. I am not saying we will be able to make use of all the contextual information on the form. However, it would be a mistake to not organize and use them. > Archetypes are designed independently of these considerations, Thus, archetypes do not contain these potentially useful contextual information. > But we want more than that to have knowledge and data > interoperability.... Except if archetypes are missing the relevant contextual information, knowledge and data interoperability will be impaired. This is one of the (covert) reasons why OIO forms map directly to screen output by default. > >The OIO architecture captures this _meaningful_ clustering of items on a > >form and uses it as the "semantic context" during report generation. The > >form-to-form translator is yet another example of how we use this > >contextual information. > > > I have no argument with OIO - I was not even trying to make any sort of > critique about it; But I am making a critique of OpenEHR :-). > I simply thought it would be useful to show a model of a BP in ADL > compared to the schema level models you and Horst were discussing... Which is wonderful because I learned more about OpenEHR and had another chance to describe OIO to you. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
