The culprit is lack of time... as usual....
So far I have created a simple test LINK archetype, showing how a
jurisdiction, in this case Sweden, might use it. To see it, follow these
steps:
1. if you don't have it, download the ADL workbench
(http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html)
2. SVN checkout or update http://www.openehr.org/svn/knowledge2/ -
this will get both the latest test archetypes, and the required
updated RM schema file, called openehr_rm_200exp.dadl
3. you will have to install the new RM schema manually, by copying it
from the rm_schemas directory in the above checkout, to the
directory of the same name in the ADL Workbench install area /
rm_schemas directory (i.e. C:\program files\openEHR\ADL
workbench\rm_schemas, on Windows).
4. To see the test archetypes, create a profile in the ADL Workbench
for the path
...\knowledge2\TRUNK\archetypes\openEHR_examples\link_archetypes
(see here for help -
http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/learning_adl_15.html)
5. you can now compile the test Swedish specialisation EVALUATION
archetype, that adds a standard LINK archetype to the existing CKM
problem-diagnosis archetype
I have added a constraint of the 'target' property of the LINK classes,
based on a new experimental 'target_type' computed property of the
DV_EHR_URI class (added in the new schema). This shows how it would be
possible to constraint the target to OBSERVATIONs, but I am pretty sure
something stronger than that is needed, more like the semantic archetype
slot constraints described here -
http://www.openehr.org/wiki/display/spec/Towards+a+definition+of+%27slot%27+semantics
.
If anyone has problems with these steps, let me know on this list, and I
will provide further information, but normally the above should be enough.
Others are welcome to have commit access to the knowledge2 repository,
and help to grow the test archetype set, as well as experiment with
ideas on the RM schemas is welcomed.
- thomas beale
On 27/10/2010 09:56, Erik Sundvall wrote:
> Hi!
>
> I hear of a lot of interesting off-line discussions regarding the
> openEHR RM object named "LINK". I guess they have not yet reached the
> mailing list because of time restrictions and/or the
> exploratory/initial nature of the discussions. But now let's get more
> good brains involved...
>
> Just to make sure we talk about the same thing, it is the class LINK
> described in section 3.2.4 in
> http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf
> and in XML schema
> http://www.openehr.org/releases/1.0.2/its/XML-schema/documentation/Structure.xsd.html#h518145503
> (An excerpt from the spec is attached by the end of this mail)
>
> Some of the interesting bits I've picked up so far from discussions:
> - Maybe it would be a good idea to make LINK inherit from LOCATABLE
> and thus become archetypable in itself
> - Tooling support for using LINK in archetypes is currently poor or non
> existent
> - There is very little (if any) reported usage experience of LINK in openEHR
> - I believe the NHS has somewhat explored LINK usage in LRA using ISO 13606
> - If archetyping LINKS, then it would in _some_ cases be desirable to
> be able restrict the type of the "target", especially defining what
> archetypes the target objects must adhere to (similar to the archetype
> slot mechanism).
>
> Please fill in with nore details and thoughts.
>
> Implementers, would it have a big impact on your implementations if
> LINK was made LOCATABLE? (Let's say in v 1.0.3)
>
> I wonder, is it currently safe to archetype the DV_EHR_URI used in the
> "target" attribute of LINK just using a string matching pattern or do
> we need additional mechanisms? The URI value represents an identifier
> of some node inside a versioned object, do string patterns matching
> DV_EHR_URI values cover for all kinds of target range restrictions
> we'd likely want to express if archetyping LINKs? Maybe they actually
> do work using wildcards in the right places? How tricky will it be to
> implement that constraint checking at runtime data creation?
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
>
> Excerpts from section 3.2.4 in common_im.pdf:
>
> Purpose:
> The LINK type defines a logical relationship between two items, such as two
> ENTRYs or an ENTRY and a COMPOSITION. Links can be used across compositions,
> and across EHRs. Links can potentially be used between interior (i.e. non
> archetype root) nodes, although this probably should be prevented in
> archetypes.
> Multiple LINKs can be attached to the root object of any archetyped structure
> to
> give the effect of a 1->N link
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
> Use:
> 1:1 and 1:N relationships between archetyped content elements (e.g. ENTRYs)
> can be expressed by using one, or more than one, respectively, DV_LINKs.
> Chains of links can be used to see ?problem threads? or other logical
> groupings of
> items.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
> MisUse:
> Links should be between archetyped structures only, i.e. between
> objects representing
> complete domain concepts because relationships between sub-elements
> of whole concepts are not necessarily meaningful, and may be downright
> confusing.
> Sensible links only exist between whole ENTRYs, SECTIONs, COMPOSITIONs
> and so on.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
>
> Attributes :
>
> [1..1] meaning: DV_TEXT
> Used to describe the relationship, usually in
> clinical terms, such as ?in response to? (the
> relationship between test results and an order),
> ?follow-up to? and so on. Such relationships
> can represent any clinically meaningful connection
> between pieces of information.
> Values for meaning include those described in
> Annex C, ENV 13606 pt 2 [11] under the categories
> of ?generic?, ?documenting and reporting?,
> ?organisational?, ?clinical?,
> ?circumstancial?, and ?view management?.
>
> [1..1] type: DV_TEXT
> The type attribute is used to indicate a clinical
> or domain-level meaning for the kind of link,
> for example ?problem? or ?issue?. If type values
> are designed appropriately, they can be used
> by the requestor of EHR extracts to categorise
> links which must be followed and which can be
> broken when the extract is created.
>
> [1..1] target: DV_EHR_URI
> The logical ?to? object in the link relation, as
> per the linguistic sense of the meaning attribute.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
> End of excerpts from section 3.2.4 in common_im.pdf
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101027/4c978335/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101027/4c978335/attachment.jpg>
