Thank you... this is becoming clearer from the clinical/business-process perspective. I still have this lingering concern about the inherent freedom and flexibility afforded by archetypes being somewhat in conflict with the need for interoperability. Let me see if I understand by reflecting a specific example of a physician ordering a pair of Rx spectacles from a lab:
The "ontology" (which seems roughly synonymous with "data dictionary" and "standard terminology" a la SNOMED) would be a listing of all the "atomic" terms unique to specification of an Rx lens, along with industry-standard, unique definitions: SpherePower: "The diopteric power of the blah, blah, blah..." MinusCylinderPower: "The algebraic difference blah, blah, blah..." CylinderAxis: "The angle represented by the blah, blah, blah..." etc., fully specifying the data types, ranges of acceptable values, units of measurement, and somehow stipulating that only "quarter" and "eighth" diopter values are used. E.g., "-3.25" and "-3.37" are acceptable, but "-3.90" is not an acceptable value for the unit, "diopters". Cylinder axis is express in whole degrees with legal values from "1" to "179", etc.. Then we could define an Archetype called "BasicLensFormula-MinusCylinderNotation", which is a combination of SpherePower, MinusCylinderPower, and CylinderAxis, more or less "strung together". The Order specification message to the lab would require, amongst other things, the "BasicLensFormula-MinusCylinderNotation" for the right lens and the "BasicLensFormula-MinusCylinderNotation" for the left. Is this understanding correct so far? If I am using these terms and concepts correctly, then it seems to me that the most critical objects for doctors and other users to agree on INITIALLY and memorialize as a "standard"... across the region that wishes to experience "interoperability"... would be the basic ontology... correct?? If the ontology is the listing of "atoms", then Archetypes would appear to be the "molecules"... and also something that would be helpful to attempt to standardize across the "interoperability region/domain". But due to the inherent "anything goes" aspect of defining Archetypes, and the flexibility in system design that accompanies it, we might have a harder time getting users to agree on standard Archetypes. If 80% of the most common "molecular" concepts, however, could be agreed to at the SDO level, then that would seem to be in everyone's interest. I will assume that I'm still "on the right track" and take my question to one more level. Would it make sense, then, for the SDO to continue accepting Archetype definitions that are useful to some in the domain... even though they might be extensions or conglomerations of other Archetypes? ... and for the SDO to maintain all of them together in its library of "standard archetypes for the vision industry"? If Standard Archetype X was made from unique, atomic concepts A, B, C, and D... and a user only required A, B, and C... would he still use an Archetype X in his message schema, simply ignoring the value of D? Or would he register the combination of A, B, and C as a new Standard Archetype Y? (That's enough for one email!) Thanks. Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http://Optiserv.com http://VisionDataStandard.org ----- Original Message ----- From: "Bhupinder Singh" <bob...@sancharnet.in> To: "Philippe AMELINE" <philippe.ameline at nautilus-info.com>; <openehr-technical at openehr.org> Sent: Thursday, August 14, 2003 4:10 AM Subject: Re: IS Models (was HISTORY DATA SET IN EPR) > Hello Philippe, > What you are saying is correct. But let us review what christopher has > already said and also reiterated in my previous mail. The objective is to > have the clinicians needs fullfilled. A clinician is interested in the > following. > Does the application give me a user friendly interface. > Does the flow follow the clinical thaught process. > Does it allow the data collected to be used for a retrospective analysis. > The data entry process should be completed with the minimum key strokes. > The clinical process of analysis cannot be straight jacketed the system must > meet the clinical requirements of the clinician. > 70 % of the diagnosis is arrived at during the analysis of the symptoms and > its associated findings > Clinical compliance (read doctor compliance) is mandatory. For which the > system should give value to the clinician. Let me give you one example of > the Respiratory system. This systems in all has cardinal symptoms such as > Cough > Dyspnoea > Haemoptysis > Chest Pain > > And some general symptoms such as > Fever > weakness > etc etc > > The complete respiratory medicine ( read 80% of the time) is based upon the > findings that the clinician is able to descern out of these symptoms and > assocoaited signs. If these are modelled and are available along with the > flexibility to capture the information and then have the free text for the > elements that are not modelled. > > The clincial analysis process is pretty much standard all over and this will > find acceptability (hopefull). The data so captured can be used for a > descision support system. > > This is an add on to your thaughts and maybe you can now look at your > suggested solution in the light of what would find acceptance with a > clinician. > > Dr B S Grewal > > ----- Original Message ----- > From: "Philippe AMELINE" <philippe.ameline at nautilus-info.com> > To: <openehr-technical at openehr.org> > Sent: Thursday, August 14, 2003 1:14 AM > Subject: IS Models (was HISTORY DATA SET IN EPR) > > > > Hi, > > > > When you build an information system, you have to create a solid structure > > in order to have people fill it with datas, just like a building is made > of > > concrete, or steel or wood, but anyway stands up alone. > You are correct in as far as this is concerned. > > > > Most information systems have a structure made of a database, openEHR is > > innovative with the far more flexible Archetypes ; what about ontologies ? > > > > To explain it, we can keep on with the model of a solid structure that > > allows the system to "stand up", but instead of the building example, we > > will shift to a note-book example : > > > > With a "Database structure", the note-book would already be fully > > pre-printed with a given set of forms. If they don't fit your needs, you > > still have to cope with. > > > > With an "Archetype structure", you are presented with a blank note book > and > > a set of stamps to create the forms you want where you want (and you can > > get new stamps if you need it). It is the Archetype "2 levels" model : the > > information that makes the system stand up is in the stamps - it can make > a > > form you can fill on the note-book. > > > > With an ontology, things are more subtle since whats make the system stand > > up is the couple "word + semantic". To keep on with the note-book example, > > I would say that you no longer need forms, you simply have to use the > terms > > of the ontology and make sentences with them. It works because what you > > "write" has a meaning for the system. > > Of course, you can also use stamps sometimes (Archetypes) to speed the > > writing and ease the reading (repetability), but the semantic is in the > > words themselves and not in the form (I mean you even could forget the > > Archetype afterward - of course it won't be smart, but it would still > work). > > > > I don't know if this model helps to understand the genuine concepts behind > > ; however, it is pretty close from the way we build Odyssee. > > > > Best regards, > > > > Philippe > > > > >Christopher Feahr wrote: > > > > > >>. but my understanding was the the SNOMED people had > > >>already modeled complaints, signs/symproms, diagnosis, treatment plans, > > >>prognosis, outcomes... the whole 9 yards. If that is true (seems too > > >>good to be true!) then it may only require a (simple??) mapping of > > >>SNOMED CT to a collection of EHR Archetypes. > > >this is a bit question. The key thing to remember is that: > > > > > >- terminologies/ontologies (attempt to) model reality, e.g. their model > of > > >symptoms related to tropical parasite infections will/could be a detailed > > >semantic net of nodes describing in great detail the symptoms at every > > >point of e.g. plasmodium lifecycle during malaria infection - textbook > > >stuff in other words. > > > > > >- but the doctor in a hospital is interested in recording observations > > >about the patient, ordering tests, making decisions, following progres > and > > >so on. The information he/she wants to record and read is to do with the > > >observation and care process, not with the scientific description of the > > >life history of plasmodium. This is the area of archetypes and > templates - > > >providing highly configurable models of this information and processes, > > >during the clinical care path. > > > > > >- terminologies are necessary as a knowledge base during the use of > > >archeytpes - they provide names of things of course, but more > importantly, > > >semantic networks support inferencing. So one can imagine a doctor > > >recording symptoms and signs in their info system, and thinking that so > > >far, it could be malaria or some other fever-inducing infection... if > they > > >have detailed enough observations, it may be that the ontology can > provide > > >some guesses as to what the patient has. > > > > > >So - we have two kinds of models here: terminology/ontology is about > > >modelling the real world, and facts we have learned and appear to be > > >dependable; archetypes and templates are about modelling patterns of > > >information *in use*, and they depend on ontology for meaning of items > > >they mention. Archetypes provide for a lot of optionality, whereas this > is > > >not part of ontology (except ontologies modelling decision making > > >processes themselves perhaps). > > > > > >- thomas beale > > > > > > > > >- > > >If you have any questions about using this list, > > >please send a message to d.lloyd at openehr.org > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
