Hi Thomas,

2006/11/12, Thomas Beale <Thomas.Beale at oceaninformatics.biz>:
>
> Mattias Forss wrote:
> >
> >
> >         * in some cases, most likely what is really needed is to be
> >           able to reduce the work required to build archetypes in the
> >           authoring tool environment - in other words cut and paste,
> >           or smarter things than that. So - what is smarter than cut
> >           and paste? We can consider that there are "archetype
> >           fragments" which are stored and indexed in a sophisticated
> >           authoring environment. These would not be separate
> >           archetypes as such - just pieces of archetypes that have
> >           been identified as re-usable in the authoring environment,
> >           but otherwise not sensible self-standing semantic units.
> >           Think about it this way - in some cases, you are not after
> >           another archetype, you just want to make sure that you build
> >           the little piece of the current archetype inn the same way
> >           as you did last time, without missing a term.
> >
> >
> > Agree, but shouldn't there be some way to link the "copies" with each
> > other, because they _will not_ be the same data if they don't have the
> > same archetype path? How should we know if we already entered similar
> > values in another archetype, possibly even found in another template
> > than the current one? There should be some way of linking values
> > together. Can it be done at the template level or must it be done at
> > an even higher level, i.e. in business logic of the GUI in the EHR
> system?
> not sure what you mean here. If I make a copy of a piece of an archetype
> that is in some "archetype fragment library" into archetype A and
> archetype B, these two archetypes will have the correct archetype paths
> according to where the fragment was put. When you say "data" and
> "values" are you talking about when the archetypes are used at runtime
> to create EHR data?


Archetype A and archetype B will have 'correct archetype paths according to
where the fragment was put', but will they refer to the same paths? When I
talked about data I meant what was stored in the EHR system and when I
talked about values I meant what was entered in the template.

I tried to ask if there is some way to make two or more archetypes
manipulate exactly the same data in an EHR system, meaning that the
archetypes probably must refer to the same paths - otherwise the data will
be manipulated at different places and the system must know that the data at
the different places are actually the same. Consider this example:

Archetype A is used in a template to create data about a patient's weight
and archetype B is used in another template and will also create data about
the weight. However, if the weight data was already entered in the EHR
system, is there a way (to create archetypes) which make the system know
that it deals with the same data no matter if it came from archetype A or
archetype B and fetch the last entered value to any of the templates that
need the weight information?

>
> > I will probably make it possible in the Java archetype editor to copy
> > definition nodes between different instances of the program, but that
> > is just a start. The ideal would be to support imports of nodes found
> > in the definition of several selected archetypes...
> it might - but I wouldn't rush with too much new functionality. There
> are other priorities in my opinion, such as:
>
>     * getting a testing programme going, and getting user feedback
>     * connecting the editor to openEHR and other terminologies (such as
>       an instance of the Ocean Terminology Server, designed specifically
>       for archetype linking to Snomed and other terminologies)


Yes, of course there are more important things like these to prioritise
first.

> Yes, this condition would of course only be added in the template
> > since it is not a global requirement (however there may be such also),
> > but the invariants seem to have a lot of potential and would
> > significantly aid decision support.
> they will, but they are harder to process - we need to get more people
> using the tools for now with the basic functionality, and invariants
> developing more slowly as the user community starts to understand what
> it really wants to do with them.


Agree. I also must point out that I meant data entry support above, and not
decision support.

>> Another feature is value reporting, which should work when we use
> >> several archetypes in an openEHR template. For example if some
> >> question was answered in one archetype, then another archetype that
> >> has the same question should get the value reported from the previous
> >> archetype. Is this possible? I guess this has to do with external
> >> references as I mentioned in my first question.
> >
> >     you normally would not allow this in the template if the values
> >     were meant to refer to the same thing (i.e. only entered once by
> >     the user); if this is not the case, you could add an invariant to
> >     the template.


I meant if we use two different templates, i.e. values are not entered in
the same template. Please see the weight example above.

Regards,

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/b1c4d490/attachment.html>
-------------- next part --------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Reply via email to