> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> > I disagree, provided that openEHR-style Archetypes are used. I am
> > beginning to appreciate more of the magic of this now. Archetypes
> are
> > built from a small set of reference classes (information types and
> > models for generic things like PERSON, ROLE etc). Archetypes are
> > descriptions of higher level constructs, like PHYSICIAN, PATIENT,
> > TEST-RESULT, expressed semantically through sets of constraints
> (i.e.
> > using a defined constraint language). Archetypes can then be
> further
> > specialised (subclassed) by specifying more constraints, so if Dr A
> > wants to specify a class for Serum Rhubarb concentration, she can.
> Dr
> > B's system will be able to understand the Serum Rhubarb class 
> > definition
> > (and the actual result, 23.4 mg/l, and the units etc) because Dr
> B's
> > system shares the same reference models and Archetype library 
> > as Dr A's
> > system (or Dr B's system can look up the Archetype library). Dr A's
> > system  sends both the result and the definition for the Serum
> Rhubarb
> > class. Note that the definition of the Serum Rhubarb class may
> include
> > things like how the concept of Serum Rhubarb fits into various
> > ontologies of medical knowledge.
> 
> This seems to be clear, but how do you accomodate ongoing
> developments? I
> mean when there is no archetype available for the notes the user
> wants to
> make, or the available archetype is not elaborate enough. Do you
> include a
> "miscellaneous notes" parts into each archetype to bridge the gap
> between
> the moment of note-taking and the moment an appropriate archetype is
> available? With TEST-RESULT I can imagine that the overall structure
> of the
> generated data/result is similar so a name "field" describes the
> exact test
> done. Or would you inherit a specialized archetype from this generic
> TEST-RESULT to accomodate each and every possible test?

I don't know the answers to these questions, but it seems clear that this is teh 
area in which Archetypes and openEHR will sink or swim: getting the "social 
infrastructure" of Archetypes right. Clearly there are tensions between 
decveloping a common set of reference models and basic Archetypes, and the 
need for flexible specialisation of existing Archetypes and the creation of new 
ones. Many lessons can be learnt from the OMG/Corbamed and HL7 experience: 
that a closed "reference group" which you have to pay to join is not the right way 
to go. But a complete free-for-all won't work either. And there need to be many 
levels of commonality - at the global, national, regional and local levels. 
Developing this social infrastructure is probably the biggest challenge for 
openEHR and Archetypes, I think.

> 
> > c) will the reference models be complete and general enough?
> 
> This I don't understand. I would think that in order to be truly
> "exchangeable" there would be only one Reference Model which has a
> few
> 'static' concepts from which all objects, generated by archetypes are
> derived. In layman's terms: I can build structures with Lego blocks
> and I
> can build structures with KNEX, but I can't exchange Lego blocks with
> KNEX
> parts.

Perhaps I should have said: will the primitives available in the Reference Model 
be general enough i.e. have they defined a broad enough range of Lego blocks to 
enable everything that is needed to be built? The answer will be no, but what's 
important is whether there are enough to get started with. The answer to that is 
likely to be yes.

Cheers,

Tim C

Reply via email to