I have created a wiki page to describe a possibly radical idea about how we define value sets (like body position etc) in archetypes.
all feedback welcome.
- thomas
Thomas and All,
[Sent to CIMI-list as well... Sorry for cross-posting]
From what I can see the
difference, apart from syntax, from the current AOM is that value sets
are named objects by themselves. This would actually solve the problem
of
implementing the proposed CIMI terminology binding model in archetypes:
(using openEHR terminology biniding terminology) OBJECT bindings would
be term bindings of value sets, VALUE SET bindings would be assignment
of at-codes to value sets. Then it's just figuring out how those kinds
of bindings are to be used and explained to archetype users...
I see a number of alternative syntaxes for assigning at-codes to value
sets though, e.g.
["vs1001"] = <
text = <"Blood pressure measuring position">
description = <"Position of patient at time of measuring blood
pressure.">
content = <"at1001"> <"at1002"> ...
>
or
["at1001"] = <
text = <"Standing">
description = <"Standing at the time of blood pressure measurement.">
valueset = <"vs1001"> <"vs1009">...
>
This would probably enhance readability, as a archetype reader would
have to look in two places and not three places to determine the
contents of a value set.
Cheers,
Daniel
I like the idea, we were already exploring something similar to this for intra-archetype semantic relationships.
I have two questions/suggestions:
-once the vsXXXX is intoduced, do we still need to specify it as “local”. Wouldn’t be always be local from now on?
-I would suggest to use directly rdf triplets in the relationship part. I think the proposal is too verbose. Also, it would be great if we could define a set of relation types
Thomas and All,
[Sent to CIMI-list as well... Sorry for cross-posting]
>From what I can see the
difference, apart from syntax, from the current AOM is that value sets
are named objects by themselves. This would actually solve the problem
of
implementing the proposed CIMI terminology binding model in archetypes:
(using openEHR terminology biniding terminology) OBJECT bindings would
be term bindings of value sets, VALUE SET bindings would be assignment
of at-codes to value sets. Then it's just figuring out how those kinds
of bindings are to be used and explained to archetype users...I see a number of alternative syntaxes for assigning at-codes to value
sets though, e.g.["vs1001"] = <
text = <"Blood pressure measuring position">
description = <"Position of patient at time of measuring blood
pressure.">
content = <"at1001"> <"at1002"> ...
>or
["at1001"] = <
text = <"Standing">
description = <"Standing at the time of blood pressure measurement.">
valueset = <"vs1001"> <"vs1009">...
>This would probably enhance readability, as a archetype reader would
have to look in two places and not three places to determine the
contents of a value set.
Yep, I'm ok with any of those. One version I originally thought of - Daniel's first alternative above:
["vs1001"] = <
text = <"Blood pressure measuring position">
description = <"Position of patient at time of measuring blood pressure.">
content = <"at1001", "at1002", "at1003", ...>
We can put more or less any alternative that works - happy to see what the discussion here might generate.
- thomas
good point. I’ll have to think about that, although even if we think “vs1001” is ‘obviously’ an ‘archetype’ code, but there’s no guarantee some external terminology doesn’t have a code like “vsNNN” so for now I’d like to keep “local”. I’m not religious about it - if we can convince ourselves we can throw it out, fine by me. That’s sort of what I was trying to do, but in ODIN (i.e. dADL). I don’t like raw RDF, but we could do something like . We can do two things - we either embed real Turtle (or whatever) syntax, or we ODIN-ise it, which means that it can be deserialised in to in-memory objects that follow an RDF triple model. The second option is nicer from the software point of view, because it avoids having too many different syntaxes in one document, and a generic deserialiser (which we have for ODIN/dADL in various languages) will just convert it into objects. But I’m not against doing it the other way either if that made more sense. - thomas
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
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.
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@luna.nl
I agree with all of that - this is more or less why it wasn't done this way before. It might need to be a 1.6 or 2.0 addition...
- thomas
HI all,
I agree with Daniel’s idea: having the terminology items physically inside the value set, so the value set itself will be a new terminological construct and we’ll have both: terms and sets. This is clearer and simpler than havnig external relationships (is simpler to parse, implement in code and traverse the structure by a program).
BTW, I would prefer that “ontology” section would be called “terminology” in future versions of ADL/AOM. IMO this is more correct naming.
Hi Pablo,
This makes a lot of sense to me as well.
Re ontology section there may be terminology service queries to things like snomed or formal ontologies. So I'd assume what comes back could potentially be considered as an ontology. Also bear in mind there is no agreed separation of what is terminology vs ontology as far as it goes so sticking to ontology is probably more inclusive for now. I think one needs to consider usage rather than composition for correct labelling - so for example a group of snomed terms that form a value set can be considered as terminology on the basis of usage but results of a terminology service returning a hierarchy of terms will look more like an ontology. Anyway I'm sure this is more an academic concern than real 
Cheers,
-koray