Intra-archetype semantic relationships

Gerard Freriks gfrer at luna.nl
Wed Jan 15 04:49:37 EST 2014


Do I understand that one of the proposals is to have an external resource define what the archetype is?

For SIAMM we decided that all the data that describe all relevant semantical aspects of the archetype must be defined inside that archetype as part of the archetype pattern.
External services can use that data to manage the archetype libraries.
That relevant data is to be found in the MetaDataArtefact branch of the pattern and in the Name and NameType parts.

- MetaDataArtefact describes general aspects of the artefact.
 (what class of the RM, applicable ContSysTerm, how the artefact is used in the EHR-system (e.g. presentation, exchange, etc.),
  what aspect of healthcare provision the artefact is used for (diagnostics, Treatment, Administrative, Management, Re-Use, etc.)
- Name and NameType give the specific name related aspects of that artefact. (e.g. NameType:LabFinding, Name=BloodSerumGlucose)

The Slot Mechanism must rely on this data inside  the archetypes for the (de-)selection of candidate slot fillers.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 15 jan. 2014, at 10:09, Diego Boscá <yampeku at gmail.com> wrote:

> I agree that sometimes regular expressions can be tricky, and surely they don't look pretty on its current form. However, but they have an advantage: They are formal and easily evaluated in any language. The problem I see with this approach is that you will need a single ontology (or access to it) to be able to assure that the meaning is the same for everyone. Also you will have to forbid more radical changes that are being made on the archetypes (changing its root entity, for example).
> 
> Also, if this approach is taken, precise rules and clarifications are needed. e.g. in the last example, are 'massage' children allowed? (in other words, does EXCEPT refer to the children too or not?). Are there some kind of precedence rules implied? These kinds of things should be formally defined in any case.
> 
> 
> 2014/1/14 Thomas Beale <thomas.beale at oceaninformatics.com>
> On 14/01/2014 11:07, Diego Boscá wrote:
> I like the idea, we were already exploring something similar to this for intra-archetype semantic relationships.
> 
> 
> Since Diego brought up the topic....
> 
> one of the final things needed in ADL/AOM 1.5 is a better kind of slot, which works off an ontology of archetypes. The question is: is the ontology hierarchy defined by their specialisation relationships (and going up into the categories Observation, Evaluation etc) or by some independent ontology? The former would be automatically extractable from the specialisation relationships of a population of archetypes, but the latter is more likely to work as needed. Anyway, assuming that the ontology can be established (e.g. in CKM or somewhere), new slots would look something like:
> 
> items matches {
> 
>     allow_archetype CLUSTER[id24] matches {< device_description OR << manual_procedure}
> }
> 
> Where 'device' means CLUSTER archetypes classified under a device_description node in the ontology. The '<' means any child (but not this concept), '<<' means this concept or any child. The value of this approach is that you may define your slot and publish your archetype, then some time later, you realise you need to allow a new archetype to be a slot filler. Assuming that the new archetype can be reasonably classified as a 'device' or 'manual procedure' then you do this in the ontology, and your slot definition now evaluates to pick up your new archetype - no changes needed to either archetype.
> 
> More complex constraints could be defined:
> 
> items matches {
> 
>     allow_archetype CLUSTER[id24] matches {< device_description OR << manual_procedure EXCEPT massage }
> }
> 
> These kinds of expressions start to look like ref-set definitions, where the ref-set are being defined on the archetype ontology rather than some external terminology like SNOMED. If the archetype ontology were defined in a SNOMED extension or similar, the same technical tools could be used to evaluate slots.
> 
> - thomas
> 
> 
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140115/0c955916/attachment.html>


More information about the openEHR-technical mailing list