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?
>
> 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)
>
> the first "exists" is only needed if the systolic value node is
> optional; the above statement in a real archetype would not
> necessarily be exactly as above, but the idea is clear. HOWEVER:
> in clinical terms, this sort of condition may not be considered as
> globally applicable as the rest of the archetype - it might only
> apply in your hospital. In this case, the same kind of statement
> should be added to a template instead.
>
>
> 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.
>
>
>> Another issue is about computation. For example we could want a
>> quantifiable magnitude to be the result of two previously entered
>> values. Is this possible to do in archetypes? Perhaps in the
>> declaration section or the invariant section?
> this can also be done in the invariant section using a statement
> of the form:
>
> exists(/path1/value) and exists(/path2/value) implies
> /path3/value = /path1/value + /path2/value
>
>
> Though it certainly is useful, this is only to constrain the allowed
> value and not to compute it. Some business logic in the EHR system
> would have to use the invariant to compute the allowed value so that
> the clinician doesn't have to do that (and risk to enter the wrong
> value and break the data entry process if the value is invalid
> according to the archetype).
this is usually correct.
>
> I also noticed that archetypes may become ambiguous by using
> invariants. For example if the cADL says that the value must be > 10
> and the invariant says that the value is 5. I guess there is a need
> for an archetype validator that checks all kinds of things,
> conformance to RM class names and attributes, existing codes in the
> ontology section, invariants conforming to cADL, etc, etc.
it just means that there cannot be mutually incompatible constraints on
a given node - which is one reason why invariants require more careful
implementation.
>>
>> 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.
>
>
> What if the values should refer to the same thing across different
> templates, that uses different archetypes? How should the values be
> linked then, can invariants still solve that?
I think the application will have to solve this, possibly by keeping
track of which template paths have already had values entered for them...
>
>> We would also like to ask if there is a way of specifying
>> validity for questions depending on previously answered
>> questions. E.g. if a certain answer was given from a multiple
>> alternative question (coded_text), then and only then, some other
>> group of questions will be valid. Is this possible to do in
>> archetypes? Perhaps it's possible with invariants?
> same general form as the first one, where the exists() quantifier
> can be used with operators like "implies" to state the required
> conditions.
>
>
> Does this mean that the invariant allows something like
> "path/to/coded_text/defining_code = at0003 implies /some/path[atNNNN]
> occurrences.min = 1" can be used for the group of questions (cluster)
> we want to be valid?
yes, although the predicate logic would be more like:
path/to/coded_text_attr/defining_code = [local::at0003] implies exists
(/some/path[atNNNN])
>
>> Finally is there a way of specifying the relevance of answers in
>> archetypes. Say for example that if some laboratory results are
>> too old, could an archetype contain some restrictions that make
>> it illegal to answer certain questions because the material that
>> the answers are based upon is too old? I'm not sure if this is
>> related to DSS or something else.
> this sounds more like an application or DSS area. However, it
> would not be impossible to create invariants to do what you want -
> a typical example would be for microbiology test samples - the
> invariant could state that the sample date/time has to be within X
> days of $today. We don't quite have all the variables defined for
> this yet, but it is not far off.
>
>
> Okay, it seems to me that many invariants could be added at a local
> template level to aid basic decision support. This is quite interesting.
it is the pandora's box of archetypes ;-)
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
