Good summary by Erik and quick response by Thomas =) Some thoughts on this 1. It seems the LINK constraints can be used to express logical associations between clinical process steps, e.g. a EVALUATION.health_issue archetype has a LINK to a EVALUATION.care_plan archetype which in turn has several links to specific order archetypes. If this is about a condition specific clinical process, i.e. a clinical guideline, these constraints should most likely to be expressed on the template level.
2. In runtime, these LINK archetypes can be used to load relevant archetypes for the details of the next step according to the process definition. From this perspective, this type of constraints are used differently than 'ordinary' archetype constriants. 3. The new "target_type" attribute seems to be a good start. We probably need something like allow_archetypes to express detailed inclusion criteria on archetypes, and perhaps even templates. Cheers, Rong On 27 October 2010 17:58, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 27/10/2010 13:28, Erik Sundvall wrote: > > Wow Tom! > That was a fast, nice and somewhat unexpected answer, now we're just > awaiting the caption text to explain the image :-) > You at least got me poking around for the archetypes, finding > http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/link_archetypes/ > > - So tooling support already does exist, AWB for viewing & validation and > text editor for editing :-) (Or is there more?) > > I don't think editing capability in the AWB will be out of the question in > the near-ish future, but I don't have any bandwidth to go there right > now.... > > - What about the target range constraints, will string matching expressions > cover all likely use-cases? > > well I think string matching can work, but any lexical matching to achieve > semantic purposes is always dodgy. I think we need to be more careful with > how we do this, but I have not analysed it that much yet. > > - This means a small modification (inherit LOCATABLE) to the LINK class in > the RM to make the reference to used archetype possible to store in the EHR, > right? > > yep - see the experimental RM schema file (you could diff it with the 102 > file and you would see the addtions; they are also explained at the top). > > (The "un-archetyped" LINK information storage is already supported I > believe, so data entered this way would be readable in the current 1.0.2 RM, > even if archetype info will not be present, is that correct?) > > yep - there would just be no at-code. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
