Useful openEHR terminology Links on specifications page
There are now some useful links to get to any openEHR terminology group on the specifications home page <https://specifications.openehr.org>(scroll down) in one click. - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Archetyping links
Hmm, interesting idea. H -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Peter Gummer Sent: Wednesday, 10 June 2009 5:50 PM To: For openEHR technical discussions Subject: Re: Archetyping links Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
yes, I meant properties of their targets as grounds
for constraining them
Grahame
-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel
Sent: Tuesday, June 23, 2009 10:00 AM
To: 'For openEHR technical discussions'
Subject: RE: Archetyping links
Hi Grahame,
No, I don't think, not directly anyway. The URIs are based on paths which
obviously utilise the archetype and node IDs from Archetypes, but each
implementation of a particular archetyped concept may be in a different
location within a composition (i.e. a different template) so the path part
of the URI will be different. In addition, URIs are for a particular
instance, more like an Instance identifier than a concept code. Therefore,
the only things that I think can be used to constrain a EHR URI is meta-data
about the target (rm_type_name, archetyped parent archetype ID, archetype
path) rather than the runtime URI of the target itself. Perhaps this is
what you meant.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Grahame Grieve
Sent: Wednesday, 3 June 2009 9:45 AM
To: 'For openEHR technical discussions'
Subject: RE: Archetyping links
Hi Heath
Doesn't this imply that a URI's are like codes that are
references to some concept - that there's the same interest
in controlling the concepts that they point to, and
a similar delegation of control as with terminologies (as
in, early vs late binding, implementation provision issues)?
So that would suggest that the existing terminology stuff
in archetypes and templates points towards a solution?
Grahame
-Original Message-
From: openehr-technical-bounces at openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath
Frankel
Sent: Wednesday, June 03, 2009 9:55 AM
To: 'For openEHR technical discussions'
Subject: RE: Archetyping links
Hi Rong,
Ocean certainly has runtime support for LINKs. The Ocean Archetype
Editor
used to (and perhaps it is still there) have an initial implementation
of
constraining LINKs but it became unclear if this was viable, useful or
appropriate. We tend to now think it is a template constrain if
anything.
The common use cases we have used links is between compositions,
whereas
your example below tends to be a relative uri within the current
compositions, which is quite legitimate but I want to ensure we
consider the
more general case. For absolute URIs, the URI pattern becomes
difficult to
determine because you have version specific URIs, relative version URIs
(e.g. latest_trunk_version), and system specific URIs. In addition,
your
example assumes an exact understanding of the composition structure in
which
the target is located, i.e. that the diagnosis exists within some
section.
This is most likely not know at the time of creating the archetype with
the
LINK and likely to be variable. Wildcards and RegEx patterns can make
this
possible but start to get very complicated.
It is for these reasons that it became unclear how we can constrain the
target URI in an archetype. I have considered some extensions to AQL
to be
able to query compositions that contain LINKs to specific object types.
I
would need to review these thoughts but from memory it was along the
lines
of the following.
... CONTAINS LINK CONTAINS EVALUATION
e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/...
The point here (and it may not be clear from my attempt to relate it to
AQL)
is that there may need to be some indirect constraint required for
LINKs,
i.e. something that does not physically exist in the current instance
such
as a constraint on the target URI, but something that makes a assertion
about the real target of the URI.
I don't think there is an easy answer to these questions and only
implementation and ongoing discussion is likely toi find viable
solutions.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-
technical-
bounces at openehr.org] On Behalf Of Rong Chen
Sent: Tuesday, 2 June 2009 7:04 PM
To: For openEHR technical discussions
Subject: Re: Archetyping links
Just want to be more specific about the questions (Daniel and I are
working together on this issue), I created the ADL following the
example from Daniel's post.
ELEMENT[at0002.1] matches { -- Diagnosis
value matches {
DV_CODED_TEXT matches {
defining_code matches {[ac0.1]
}
}
links matches {
LINK[at0003.1] matches { -- complication of
target matches {
DV_EHR_URI matches {
Value matches
{/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/}
}
}
}
}
The ADL is created manually, so it might not have
Archetyping links
Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter
Archetyping links
Yes, indeed! It's a choice between composition versus association. Cheers, Rong 2009/6/10 Peter Gummer peter.gummer at oceaninformatics.com: Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Hi Rong,
Ocean certainly has runtime support for LINKs. The Ocean Archetype Editor
used to (and perhaps it is still there) have an initial implementation of
constraining LINKs but it became unclear if this was viable, useful or
appropriate. We tend to now think it is a template constrain if anything.
The common use cases we have used links is between compositions, whereas
your example below tends to be a relative uri within the current
compositions, which is quite legitimate but I want to ensure we consider the
more general case. For absolute URIs, the URI pattern becomes difficult to
determine because you have version specific URIs, relative version URIs
(e.g. latest_trunk_version), and system specific URIs. In addition, your
example assumes an exact understanding of the composition structure in which
the target is located, i.e. that the diagnosis exists within some section.
This is most likely not know at the time of creating the archetype with the
LINK and likely to be variable. Wildcards and RegEx patterns can make this
possible but start to get very complicated.
It is for these reasons that it became unclear how we can constrain the
target URI in an archetype. I have considered some extensions to AQL to be
able to query compositions that contain LINKs to specific object types. I
would need to review these thoughts but from memory it was along the lines
of the following.
... CONTAINS LINK CONTAINS EVALUATION
e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/...
The point here (and it may not be clear from my attempt to relate it to AQL)
is that there may need to be some indirect constraint required for LINKs,
i.e. something that does not physically exist in the current instance such
as a constraint on the target URI, but something that makes a assertion
about the real target of the URI.
I don't think there is an easy answer to these questions and only
implementation and ongoing discussion is likely toi find viable solutions.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Rong Chen
Sent: Tuesday, 2 June 2009 7:04 PM
To: For openEHR technical discussions
Subject: Re: Archetyping links
Just want to be more specific about the questions (Daniel and I are
working together on this issue), I created the ADL following the
example from Daniel's post.
ELEMENT[at0002.1] matches { -- Diagnosis
value matches {
DV_CODED_TEXT matches {
defining_code matches {[ac0.1]
}
}
links matches {
LINK[at0003.1] matches { -- complication of
target matches {
DV_EHR_URI matches {
Value matches
{/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/}
}
}
}
}
The ADL is created manually, so it might not have the correct syntax.
But you probably get the idea anyway.
The general question is if LINK is intended to be a runtime
facilitator or something that could be used in design time
(archetyping) as well?
Secondly, what's the status of tooling support, both in authoring
environment (archetype editors) and runtime systems (querying for
instance)?
Any feedback will be appreciated!
Cheers,
Rong
2009/6/1 Daniel Karlsson daniel.karlsson at imt.liu.se:
Dear Everyone,
what are the possibilites of constraining the LINK.target attribute
(DV_EHR_UIR datatype) in an archetype? This was possible in earlier
versions of the Ocean Archetype Editor (although its use never was
clear
to me). Let's say that I want to constrain a link from an archetype
to
only allow linkage to instances conforming a specific set of
archetypes
(e.g. allowing linkage only to Diagnosis-archetype instances for
links
with complication of meaning.) Is it allowed to use a regexp
constraint on the DV_EHR_URI and include the archetype id? Is it
guaranteed that the archetype id can be used in the path as in 11.2.3
in
Architecture overview in run-time systems?
Regards,
Daniel
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Hi Heath
Doesn't this imply that a URI's are like codes that are
references to some concept - that there's the same interest
in controlling the concepts that they point to, and
a similar delegation of control as with terminologies (as
in, early vs late binding, implementation provision issues)?
So that would suggest that the existing terminology stuff
in archetypes and templates points towards a solution?
Grahame
-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel
Sent: Wednesday, June 03, 2009 9:55 AM
To: 'For openEHR technical discussions'
Subject: RE: Archetyping links
Hi Rong,
Ocean certainly has runtime support for LINKs. The Ocean Archetype Editor
used to (and perhaps it is still there) have an initial implementation of
constraining LINKs but it became unclear if this was viable, useful or
appropriate. We tend to now think it is a template constrain if anything.
The common use cases we have used links is between compositions, whereas
your example below tends to be a relative uri within the current
compositions, which is quite legitimate but I want to ensure we consider the
more general case. For absolute URIs, the URI pattern becomes difficult to
determine because you have version specific URIs, relative version URIs
(e.g. latest_trunk_version), and system specific URIs. In addition, your
example assumes an exact understanding of the composition structure in which
the target is located, i.e. that the diagnosis exists within some section.
This is most likely not know at the time of creating the archetype with the
LINK and likely to be variable. Wildcards and RegEx patterns can make this
possible but start to get very complicated.
It is for these reasons that it became unclear how we can constrain the
target URI in an archetype. I have considered some extensions to AQL to be
able to query compositions that contain LINKs to specific object types. I
would need to review these thoughts but from memory it was along the lines
of the following.
... CONTAINS LINK CONTAINS EVALUATION
e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/...
The point here (and it may not be clear from my attempt to relate it to AQL)
is that there may need to be some indirect constraint required for LINKs,
i.e. something that does not physically exist in the current instance such
as a constraint on the target URI, but something that makes a assertion
about the real target of the URI.
I don't think there is an easy answer to these questions and only
implementation and ongoing discussion is likely toi find viable solutions.
Heath
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Rong Chen
Sent: Tuesday, 2 June 2009 7:04 PM
To: For openEHR technical discussions
Subject: Re: Archetyping links
Just want to be more specific about the questions (Daniel and I are
working together on this issue), I created the ADL following the
example from Daniel's post.
ELEMENT[at0002.1] matches { -- Diagnosis
value matches {
DV_CODED_TEXT matches {
defining_code matches {[ac0.1]
}
}
links matches {
LINK[at0003.1] matches { -- complication of
target matches {
DV_EHR_URI matches {
Value matches
{/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/}
}
}
}
}
The ADL is created manually, so it might not have the correct syntax.
But you probably get the idea anyway.
The general question is if LINK is intended to be a runtime
facilitator or something that could be used in design time
(archetyping) as well?
Secondly, what's the status of tooling support, both in authoring
environment (archetype editors) and runtime systems (querying for
instance)?
Any feedback will be appreciated!
Cheers,
Rong
2009/6/1 Daniel Karlsson daniel.karlsson at imt.liu.se:
Dear Everyone,
what are the possibilites of constraining the LINK.target attribute
(DV_EHR_UIR datatype) in an archetype? This was possible in earlier
versions of the Ocean Archetype Editor (although its use never was
clear
to me). Let's say that I want to constrain a link from an archetype
to
only allow linkage to instances conforming a specific set of
archetypes
(e.g. allowing linkage only to Diagnosis-archetype instances for
links
with complication of meaning.) Is it allowed to use a regexp
constraint on the DV_EHR_URI and include the archetype id? Is it
guaranteed that the archetype id can be used in the path as in 11.2.3
in
Architecture overview in run-time systems?
Regards,
Daniel
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Dear Everyone, what are the possibilites of constraining the LINK.target attribute (DV_EHR_UIR datatype) in an archetype? This was possible in earlier versions of the Ocean Archetype Editor (although its use never was clear to me). Let's say that I want to constrain a link from an archetype to only allow linkage to instances conforming a specific set of archetypes (e.g. allowing linkage only to Diagnosis-archetype instances for links with complication of meaning.) Is it allowed to use a regexp constraint on the DV_EHR_URI and include the archetype id? Is it guaranteed that the archetype id can be used in the path as in 11.2.3 in Architecture overview in run-time systems? Regards, Daniel
Archetyping links++
Sorry, forgot the final question: Is this (see preceding email) implemented in openEHR-based systems? Regards again, Daniel -- Daniel Karlsson, PhD. Department of Biomedical Engineering/Medical informatics Link?pings universitet SE-58185 Link?ping Sweden Tel. 013-227573, Mobil: 070-8350109, Skype: imt_danka
Links
Dear Remko The link class can only be associated with either instance and we have some work to do on how to go about this. The first thing that I would say is that we may want to create a 'report' transaction archetype that has a context attribute In resonse to and then a URL to the transaction that contains the order. This would mean that we have a firm idea of the link between a report and the order (even if it was made at another site). To work in a distributed environment it would mean that any order should give the URL of the instruction in the order (even if it is an HL7 message or other artefact) If the order is an openEHR extract it carries the URL with it. To work efficiently we will need the threads to be easy to follow - this will mean that the local EHR server will have to know which links point to which transactions from other transactions - this is an indexing problem and an example of what the server can do to make this work locally. You will not know links from outside that point in - but that is OK. Another issue that will make this far easier is smart transactions (in house) - that is to say - how we store transactions in the local DB with only smart updates - so only deletions, edits and additions are stored. If we solve this at a kernel level then updating states and links will be trivial in terms of local DB work. I hope this helps - you can see why we are not worried about commercial advantage for local application vendors as there are many implementation issues for us to consider as yet. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Remko Nienhuis Sent: Monday, 12 May 2003 4:38 PM To: openehr-technical at openehr.org Subject: Introduction and question Dear list members, My name is Remko Nienhuis and I am currently working for a small Dutch company named 2Cure, which is an international medical software supplier. At this moment, my major goal in life is understanding the OpenEHR design paradigm and reference models and the way it can or will influence futureous developments on our products. I started studying OpenEHR just a couple of weeks ago, so despite the great documentation, there is still a lot to learn. One of the things I do not fully understand is how a softwaresystem should be able to relate an instruction(entry) with the futureous result of this instruction, which will in many cases be a new transaction, for instance a Radiology visit. This kind of relation, which can also be nested and then will create a kind of ehr-thread on its own, will occure rather often. Because the initiating instruction and the resulting transaction will not share the same Clinical_Context and are not the result of the same Contribution, their relation can not be derived that way. Ofcourse it is possible to put both transactions underneath the same Folder, but that won't create a relation between the instruction and a transaction. As I understand the Link class can be used to create such relationships, but in the above scenario the Link can only be created afterwards (after the second Transaction has been created). How to constrain such a relationship? I think I'm missing a major point here. Please help me out. Best regards, Remko Nienhuis. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030513/0bc41142/attachment.html
